[Freeipa-users] Need to replace cert for ipa servers

Fri Mar 27 22:42:02 UTC 2015

Rob, thank you,you have been so helpful. This appears to have worked in my sandbox environment. I was able to get the new certs for the directory server and apache, stop tracking and remove the old Go Daddy certs, put my original CA certs in the correct locations and import into the databases, then configure the services to use them. I am going to move some clients into sandbox next week(we have rhel5, 6 and SOlaris)and see how they handle the new config before rolling out to prod environment and other ipa servers.

Thank you for everything.
--------------------------------------------
On Wed, 3/25/15, Rob Crittenden <rcritten at redhat.com> wrote:

 Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers
 To: "sipazzo" <sipazzo at yahoo.com>, "freeipa-users at redhat.com" <freeipa-users at redhat.com>
 Date: Wednesday, March 25, 2015, 2:43 PM

 sipazzo wrote:
 > Ok I finally was able to get a sandbox
 environment up to test the cert
 >
 replacement. When I ran this stepgot to the cert request
 steps:
 > ipa-getcert request -d
 /etc/dirsrv/slapd-IPADOMAIN-COM -n Server-Cert -p
 >
 /etc/dirsrv/slapd-IPADOMAIN-COM/pwdfile.txt -C
 >
 '/usr/lib64/ipa/certmonger/restart_dirsrv
 IPADOMAIN-COM' -N
 >
 CN=idm2-corp.ipadomain.com -K ldap/ipa2-corp.ipadomain.com at IPADOMAIN.COM
 > 
 > I got a message
 saying the cert at same location is already used by
 > request with nickname
 "20140729215511" , same when I ran it for
 > /etc/httpd/alias. I continued on anyway
 but when I get to this step:

 You need to tell certmonger to stop tracking
 the existing GoDaddy certs,
 not that they
 would have been renewable anyway.

 You may also need to remove them from the NSS
 database(s) using
 something like:

 # certutil -D -n
 'nickname' -d /path/to/db

 I think the subject will be different enough
 that it may be ok as-is.

 The other errors are due to the fact that no
 certificate was issued.

 rob

 > 
 >  # certutil -V -u V -n Server-Cert -d
 /etc/dirsrv/slapd-EXAMPLE-COM
 > 
 > I get an error:
 >
 certutil: could not find certificate named
 "Server-Cert":
 >
 PR_FILE_NOT_FOUND_ERROR: File not found
 >

 > Although running certutil -L -d
 /etc/dirsrv/slapd-IPADOMAIN-COM/,
 >
 returns this:
 > 
 >
 Certificate Nickname                         
                Trust
 >
 Attributes
 >                   

 > SSL,S/MIME,JAR/XPI
 > 
 > GD_CA         

       CT,C,C
 > IPADOMAIN.COM IPA CA 

 CT,,
 > NWF_GD                 

    u,u,u
 > 
 > 
 > Showing that the IPA
 Dogtag cert is now listed whereas it was not
 > previously. 
 > 
 > 
 >
 ------------------------------------------------------------------------
 > *From:* sipazzo <sipazzo at yahoo.com>
 > *To:* Rob Crittenden <rcritten at redhat.com>;
 "freeipa-users at redhat.com"
 > <freeipa-users at redhat.com>
 > *Sent:* Friday, March 13, 2015 1:32 PM
 > *Subject:* Re: [Freeipa-users] Fw: Need to
 replace cert for ipa servers
 > 
 > This environment is over 350 servers, many
 of which are in production so
 > I may
 have to wait a bit for change management approval to attempt
 to
 > resolve this issue, particularly if
 you think it might break something. 
 > I
 will keep you updated on my progress. Thank you much.
 > 
 > 
 > 
 >
 ------------------------------------------------------------------------
 > *From:* sipazzo <sipazzo at yahoo.com>
 > *To:* Rob Crittenden <rcritten at redhat.com>
 > *Cc:* "freeipa-users at redhat.com"
 <freeipa-users at redhat.com>
 > *Sent:* Friday, March 13, 2015 9:21 AM
 > *Subject:* Re: [Freeipa-users] Fw: Need to
 replace cert for ipa servers
 > 
 > 
 > 
 > 
 > 
 > -----Original Message-----
 > From: freeipa-users-bounces at redhat.com
 > <mailto:freeipa-users-bounces at redhat.com>
 > [mailto:freeipa-users-bounces at redhat.com
 > <mailto:freeipa-users-bounces at redhat.com>]
 On Behalf Of Rob Crittenden
 > Sent:
 Thursday, March 12, 2015 1:52 PM
 > To:
 sipazzo; freeipa-users at redhat.com
 <mailto:freeipa-users at redhat.com>
 > Subject: Re: [Freeipa-users] Fw: Need to
 replace cert for ipa servers
 > 
 > sipazzo wrote:
 >> I
 do have other CAs (just not the master but it is available
 offline
 >> if
 >>
 needed)
 > 
 > To be
 clear, all IPA servers are masters, some just run more
 services
 > than others. It sounds like
 you have at least one CA available which
 > should be sufficient.
 >

 >> Directory server is running
 >> The apache web server is running and I
 can get to the gui ipa
 >> cert-show 1
 works
 > 
 > Ok. I guess
 the place to start is to get certs for Apache and 389-ds,
 > then we can see about using these new
 certs.
 > 
 > In the
 thread you showed that the IPA 389-ds doesn't have a
 Server-Cert
 > nickname. You'll want
 to do the same for /etc/httpd/alias before running
 > the following commands otherwise you could
 end up with non-functional
 > server.
 > 
 > These should get IPA
 certs for 389-ds and Apache. You'll need to edit
 > these commands to match your
 environment:
 > 
 > #
 ipa-getcert request -d /etc/httpd/alias -n Server-Cert -p
 > /etc/httpd/alias/pwdfile.txt -C
 /usr/lib64/ipa/certmonger/restart_httpd
 >
 -N CN=ipa.example.com -K HTTP/ipa.example.com at EXAMPLE.COM
 > <mailto:ipa.example.com at EXAMPLE.COM>
 > 
 > # ipa-getcert
 request -d /etc/dirsrv/slapd-EXAMPLE-COM -n Server-Cert
 -p
 >
 /etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt -C
 >
 '/usr/lib64/ipa/certmonger/restart_dirsrv
 EXAMPLE-COM' -N
 > CN=ipa.example.com
 -K ldap/ipa.example.com at EXAMPLE.COM
 > <mailto:ipa.example.com at EXAMPLE.COM>
 > 
 > I'd do them one
 at a time and wait until the cert is issued and tracked.
 > This will restart both Apache and 389-ds
 but it shouldn't affect
 > operation
 because the certs won't be used yet.
 > 
 > You then need to get
 the old CA cert and put it into the right places.
 > Since it is already in the PKI-IPA NSS
 database let's fetch it from
 > there.
 For giggles you should probably save whatever the contents
 of
 > /etc/ipa/ca.crt are before-hand.
 > 
 > # certutil -L -d
 /etc/dirsrv/slapd-PKI-IPA -n 'IPADOMAIN.COM IPA CA'
 -a
 >> /etc/ipa/ca.crt
 > 
 > Now add that to the
 Apache and 389-ds databases:
 > 
 > # certutil -A -n 'IPADOMAIN.COM IPA
 CA' -d /etc/httpd/alias -t CT,C, -a
 >
 -i /etc/ipa/ca.crt # certutil -A -n 'IPADOMAIN.COM IPA
 CA' -d
 >
 /etc/dirsrv/slapd-EXAMPLE-COM -t CT,, -a -i
 /etc/ipa/ca.crt
 > 
 >
 Next add it to /etc/pki/nssdb if it isn't already
 there:
 > 
 > # certutil
 -A -n 'IPA CA' -d /etc/pki/nssdb -t CT,C,C -a -i
 /etc/ipa/ca.crt
 > 
 >
 Next, verify that the newly issued certs are trusted:
 > 
 > # certutil -V -u V
 -n Server-Cert -d /etc/httpd/alias # certutil -V -u V
 > -n Server-Cert -d
 /etc/dirsrv/slapd-EXAMPLE-COM
 > 
 > Both should return:
 >
 certutil: certificate is valid
 > 
 > Next is to configure the services to use
 the new certs. I'd stop IPA to
 > do
 this: ipactl stop
 > 
 >
 Edit /etc/httpd/conf.d/nss.conf and change the NSSNickname
 to Server-Cert
 > 
 >
 Edit /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif and set
 nsSSLPersonalitySSL
 > to Server-Cert
 > 
 > Now try to start the
 world: ipactl start
 > 
 > Run a few commands:
 >

 > # ipa user-show admin
 > # ipa cert-show 1
 > 
 > Both should work.
 > 
 > Assuming all has gone well to this point,
 copy /etc/ipa/ca.crt to
 >
 /usr/share/ipa/html/ca.crt
 > 
 > Finally run: ipa-ldap-updater --upgrade
 > 
 > This should load the
 new CA certificate into LDAP.
 > 
 > This has the potential to break a whole
 bunch of your clients. It is
 > probably
 enough to just copy over the new CA cert to the right
 > location(s) on the clients. The mechanics
 of this depend on the OS.
 > 
 >> Are the TLS errors due to the mismatch
 in certs between slapd-PKI-CA
 >> and
 slapd-NETWORKFLEET-COM?
 > 
 > No, has nothing to do with the CA at all.
 The client doesn't have (or
 > trust)
 the CA that issued the LDAP server cert.
 > 
 > rob
 > 
 >>
 >>
 >> -----Original
 Message-----
 >>
 >>
 >> From: freeipa-users-bounces at redhat.com
 > <mailto:freeipa-users-bounces at redhat.com>
 >> <mailto:freeipa-users-bounces at redhat.com
 > <mailto:freeipa-users-bounces at redhat.com>>
 >> [mailto:freeipa-users-bounces at redhat.com
 > <mailto:freeipa-users-bounces at redhat.com>
 >> <mailto:freeipa-users-bounces at redhat.com
 > <mailto:freeipa-users-bounces at redhat.com>>]
 On Behalf Of Rob Crittenden
 >> Sent:
 Wednesday, March 11, 2015 7:20 PM
 >>
 To: sipazzo; freeipa-users at redhat.com
 <mailto:freeipa-users at redhat.com>
 >> <mailto:freeipa-users at redhat.com
 <mailto:freeipa-users at redhat.com>>
 >> Subject: Re: [Freeipa-users] Need to
 replace cert for ipa servers
 >>
 >> sipazzo wrote:
 >>> Thanks Rob, I apologize that error
 was probably not helpful. This is
 >>> what I see when running install in
 debug mode:
 >>>
 >>> Verifying that
 ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an
 >>> IPA server Init LDAP connection
 with:
 >>>
 ldap://ipa2-corp.networkfleet.com:389
 >>> LDAP Error: Connect error: TLS
 error -8179:Peer's Certificate issuer
 >>> is not recognized.
 >>> Verifying that
 ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA
 >>> server Init LDAP connection with:
 ldap://ipa1-xo.networkfleet.com:389
 >>> LDAP Error: Connect error: TLS
 error -8179:Peer's Certificate issuer
 >>> is not recognized.
 >>> Verifying that
 ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA
 >>> server Init LDAP connection with:
 ldap://ipa1-io.networkfleet.com:389
 >>> LDAP Error: Connect error: TLS
 error -8179:Peer's Certificate issuer
 >>> is not recognized.
 >>> Verifying that
 ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA
 >>> server Init LDAP connection with:
 ldap://ipa2-io.networkfleet.com:389
 >>> LDAP Error: Connect error: TLS
 error -8179:Peer's Certificate issuer
 >>> is not recognized.
 >>> Verifying that
 ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA
 >>> server Init LDAP connection with:
 ldap://ipa2-xo.networkfleet.com:389
 >>> LDAP Error: Connect error: TLS
 error -8179:Peer's Certificate issuer
 >>> is not recognized.
 >>>
 >>> The
 certificates are very confusing to me. I don't
 understand how
 >>> things are
 working when we have a set of GoDaddy certs in
 >>> slapd-NETWORKFLEET-COM and a set
 of the Dogtag certs in slapd-PKI-CA.
 >>> The cert in
 /usr/share/ipa/html/ca.crt looks like the original one
 >>> issued by the Dogtag cert system
 and matches the ones on the clients.
 >>> Not to further confuse things but
 the original master server that
 >>>
 signed all these certs was taken offline months ago due to
 some
 >>> issues it was having. I do
 still have access to it if necessary.
 >>>
 >>> As
 far as why the godaddy certs were swapped out for the Dogtag
 certs
 >>> it was originally for
 something as simple as the untrusted
 >>> certificate dialogue when
 accessing the ipa gui. I did not swap out
 >>> the certs so am unsure of exactly
 what happened. There is no real
 >>>
 need to use the GoDaddy certs as far as I am concerned. I
 just want
 >>> the best solution to
 the issues I am seeing as I am in kind of a bind
 >>> with the GoDaddy cert being
 revoked and needing to be replaced and
 >>> the master Dogtag certificate
 server offline. We have a mixed
 >>>
 environment with Rhel 5, 6 and Solaris clients so are not
 using sssd
 > in all cases.
 >>>
 >>> I
 know this is asking a lot but appreciate any help you can
 give.
 >>
 >> What
 is the current state of things? Does your IPA Apache server
 work?
 >> Is 389-ds up and running? Do
 you have a working IPA CA?
 >>
 >> Does ipa cert-show 1 work?
 >>
 >> If the answer
 is yes to all then we should be able to generate new
 >> certs for all the services.
 >>
 >> rob
 >>
 >>
 >> --
 >> Manage
 your subscription for the Freeipa-users mailing list:
 >> https://www.redhat.com/mailman/listinfo/freeipa-users
 >> Go to http://freeipa.org <http://freeipa.org/><http://freeipa.org/>for
 > more info on the
 >>
 project
 >>
 > 
 > --
 > Manage your
 subscription for the Freeipa-users mailing list:
 > https://www.redhat.com/mailman/listinfo/freeipa-users
 > Go to http://freeipa.org <http://freeipa.org/>for more info on
 the project
 > 
 > 
 > 
 > 
 > 