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

sipazzo sipazzo at yahoo.com
Tue Mar 24 20:20:42 UTC 2015


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:
 # 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] On Behalf Of Rob Crittenden
Sent: Thursday, March 12, 2015 1:52 PM
To: sipazzo; 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

# 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

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>] 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>
> 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/>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 for more info on the project

   

   

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150324/a74c20ff/attachment.htm>


More information about the Freeipa-users mailing list