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.

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.

On Tue, Oct 28, 2014 at 11:27 AM, Rob Crittenden <rcrit...@redhat.com>
wrote:

> 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.
>
> 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:
> https://bugzilla.mozilla.org/show_bug.cgi?id=278689
>
> 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 <rcrit...@redhat.com
> > <mailto:rcrit...@redhat.com>> 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 <
> rcrit...@redhat.com <mailto:rcrit...@redhat.com>
> >     > <mailto:rcrit...@redhat.com <mailto:rcrit...@redhat.com>>> 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
> >     >
> >     >
> >
> >
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to