<div dir="ltr"><div>You're right. When I deleted the puppetmaster certs and reran newcert.py, it worked like a champ. Presumably this is how the main cert disappeared in the first place: NSS silently overwrote it. This does mean that I won't be able to run puppet on this server, but... Well, even when I was doing it, I knew it was a bad idea. I just figured I could maybe get away with it. </div><div>Should I submit a bug someplace? From the age of that BZ I don't have a lot of faith that the actual NSS bug is going to get fixed anytime soon. But if it can be worked around in IPA (or is it certmonger?) -- perhaps simply by showing an error message -- I think that would be sufficient. Clearly this is something of a corner case. </div></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Oct 28, 2014 at 11:27 AM, Rob Crittenden <<a href="mailto:rcritten@redhat.com" target="_blank">rcritten@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Eric McCoy wrote: > Sorry it took me so long to try this and get back to you. I tried > modifying that Python script and running it, and this is what I get: > > Initializing API > Setting up NSS databases > Untracking existing Apache Server-Cert > Issuing new cert > Tracking Server-Cert > ipa: ERROR: certmonger failed starting to track certificate: Nickname > "Server-Cert" doesn't exist in NSS database "/etc/httpd/alias" > > I checked and it's right. The output of certutil -L -d /etc/httpd/alias > is... confusing, actually. So I got the above output. Then I realized > my Kerberos ticket was expired and I ought to get a new one. When I did > so, I retried the command and got the exact same output. However, this > time certutil's output is different: > > # certutil -L -d /etc/httpd/alias > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > puppetmaster/hostname u,u,u > REALMNAME IPA CA CT,C,C > ipaCert u,u,u > Signing-Cert u,u,u > puppetmaster/hostname u,u,u > > The puppetmaster/hostname entry is in there twice. The first attempt at > newcert.py is still in my scroll buffer: the puppetmaster entry > definitely only appears once until after this most recent run. I'm > starting to wonder if my attempts to create that puppetmaster cert > somehow screwed up the database. </div></div>NSS apparently doesn't like two certificates with the same subject. Nickname doesn't seem to matter in this case. I found this bug which is mail specific but seems to cover the same problem: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=278689" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=278689</a> I think the only solution is to remove the puppetmaster cert. Does it need to reside in the Apache database? rob > > > On Thu, Oct 23, 2014 at 4:05 PM, Rob Crittenden <<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a> <div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a>>> wrote: > > Eric McCoy wrote: > > Some nicknames changed to protect the innocent. The > > puppetmaster/hostname cert is nominally unrelated, though its creation > > was contemporaneous with the disappearance of server-cert so I can't > > entirely rule it out. > > > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > puppetmaster/hostname u,u,u > > REALMNAME IPA CA CT,C,C > > ipaCert u,u,u > > Signing-Cert u,u,u > > Ok, this is good. If we have ipaCert we can get a cert directly from the > CA like we do during installation. > > The attached python script should fix things up for you. > > Save it, modify it and replace subjectbase with what matches your > environment. You can get the base from an existing cert with: > > # certutil -L -d /etc/dirsrv/slapd-REALM -n Server-Cert |grep Subject > > Unless you changed it during installation it should be O=<REALM> > > Then just run the script: > > # python newcert.py > Initializing API > Setting up NSS databases > Untracking existing Apache Server-Cert > Issuing new cert > Tracking Server-Cert > > # service httpd start > > The only thing this script doesn't do is put this updated certificate in > the service record's LDAP entry. > > rob > > > > > > > On Thu, Oct 23, 2014 at 12:53 PM, Rob Crittenden <<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a> <mailto:<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a>> </div></div><div class="HOEnZb"><div class="h5">> > <mailto:<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a> <mailto:<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a>>>> wrote: > > > > Eric McCoy wrote: > > > Hi all, > > > > > > I somehow destroyed my primary IPA server's Server-Cert in > > > /etc/httpd/alias. I don't understand how or why it > happened, all > > I know > > > is that I went to restart Apache and it was gone. Apache > won't start, > > > of course, because the cert is missing. I can't issue a new > cert > > on the > > > primary because Apache is down. I tried using the > secondary, but it > > > fails saying that it can't connect to the web server on the > primary > > > (it's the same error message I get when I try to issue a > cert from the > > > primary). I can't figure out how to tell ipa-getcert et al. to > > talk to > > > the secondary and not the primary. I'm not using DNS for > service > > > discovery, so I'm not sure how the various tools figure out > where > > things > > > are. > > > > > > This is all on CentOS 6.5 with IPA 3.0.0-37. > > > > > > > > > > What certs do you have in the database? > > > > # certutil -L -d /etc/httpd/alias > > > > rob > > > > > > </div></div></blockquote></div> </div>