[Freeipa-users] Recovering from messed-up certs
Rob Crittenden
rcritten at redhat.com
Tue Oct 28 21:47:12 UTC 2014
Eric McCoy wrote:
> 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.
Well, we really need to switch to using NSS sqlite databases which
doesn't appear to have this problem. We've never qualified all the
dependencies to actually support this though.
I started looking at mod_nss today and it's pretty easy to fix support
there, https://bugzilla.redhat.com/show_bug.cgi?id=1057650
We also need to check 389-ds, the CA, the client and probably lots of
corner cases as well.
Here is the IPA ticket to track this:
https://fedorahosted.org/freeipa/ticket/4140
rob
>
> On Tue, Oct 28, 2014 at 11:27 AM, Rob Crittenden <rcritten at redhat.com
> <mailto:rcritten at 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 <rcritten at redhat.com <mailto:rcritten at redhat.com>
> > <mailto:rcritten at redhat.com <mailto:rcritten at 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
> <rcritten at redhat.com <mailto:rcritten at redhat.com>
> <mailto:rcritten at redhat.com <mailto:rcritten at redhat.com>>
> > > <mailto:rcritten at redhat.com <mailto:rcritten at redhat.com>
> <mailto:rcritten at redhat.com <mailto:rcritten at 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
> > >
> > >
> >
> >
>
>
More information about the Freeipa-users
mailing list