<div dir="ltr"><div><div><div>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" </div>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 </div>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><div><div> </div></div></div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Oct 23, 2014 at 4:05 PM, 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">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> <div class="HOEnZb"><div class="h5">> <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>