Discussion:
[Freeipa-users] Need to replace cert for ipa servers
sipazzo
2015-03-04 21:32:29 UTC
Permalink
Good afternoon, we have a freeipa 3.0.42 installation running on redhead 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It was originally configured with the built in dogtag certificate CA and then one of my co-workers added our GoDaddy certificate to the certificate bundle. My understanding is this cert is used for communication between the ipa servers as well as the clients are also configured to trust the GoDaddy certificate. We recently had to get a new GoDaddy cert so our old one is revoked. I need to figure out how to either replace the existing revoked cert with the new one or add the new one to the bundle and then remove the revoked certificate so as not to break anything.
Any help is appreciated. I am not strong with certificates so the more detail you can give the better.Thank you.
Dmitri Pal
2015-03-04 22:56:32 UTC
Permalink
Post by sipazzo
Good afternoon, we have a freeipa 3.0.42 installation running on
redhead 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It was
originally configured with the built in dogtag certificate CA and then
one of my co-workers added our GoDaddy certificate to the certificate
bundle. My understanding is this cert is used for communication
between the ipa servers as well as the clients are also configured to
trust the GoDaddy certificate. We recently had to get a new GoDaddy
cert so our old one is revoked. I need to figure out how to either
replace the existing revoked cert with the new one or add the new one
to the bundle and then remove the revoked certificate so as not to
break anything.
Any help is appreciated. I am not strong with certificates so the more
detail you can give the better.
Thank you.
You say it was running with the self signed IPA CA and than GoDaddy cert
was added to the bundle. How was it added?
IPA does not use certs for communication between the instances. It uses
Kerberos. I am not sure the DoDaddy cert you added is even used in some
way by IPA.
It seems that your GoDaddy cert is an orthogonal trust so if you
replaced the main key pair then you just need to distribute your new
GoDaddy cert to the clients as you did on the first place.
--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
Johnny Tan
2015-03-13 17:47:04 UTC
Permalink
Post by Dmitri Pal
IPA does not use certs for communication between the instances. It uses
Kerberos. I am not sure the DoDaddy cert you added is even used in some way
by IPA.
Dmitri or Rob:

Could you explain what the various uses of the IPA certs are, then? AFAICT,
the IPA masters generate a certificate for each node in the realm. Why does
it do that? I thought it was for:
- Webui/api (apache) communication over https.
- LDAP binding/communication over 636 (TLS).

But if the certs are not utilized for communication between the instances
(per statement above), what are they used for?

I'm not hijacking the thread, I'm actually in the exact same position as
OP. I replaced the self-signed IPA/dogtag CA root with one that was signed
by our own CA and am now having problems with various cert errors during
client enrollment or any other similar activity (like doing an 'ipa host-del'
directly on an IPA master).

I can post those details in a separate thread, but before I go down that
path, I want to better understand what the purpose of the certs are so I
can deterine what's the best path forward for us.

As I understand it from the docs, there are three primary ways to run IPA with
respect to a CA:
- self-signed IPA CA, this is the default
- signing the IPA CA root with an "external"/3rd-party CA
- running "CA-less" and providing all certs with the
external/3rd-party CA (depending
on what the use/purpose of the certs are, this is increasingly becoming an
attractive option but is likely also tedious in its own right)

Thanks for any insight.
Post by Dmitri Pal
Good afternoon, we have a freeipa 3.0.42 installation running on redhead
6.6 with a mix of rhel 5, rhel6 and Solaris clients. It was originally
configured with the built in dogtag certificate CA and then one of my
co-workers added our GoDaddy certificate to the certificate bundle. My
understanding is this cert is used for communication between the ipa
servers as well as the clients are also configured to trust the GoDaddy
certificate. We recently had to get a new GoDaddy cert so our old one is
revoked. I need to figure out how to either replace the existing revoked
cert with the new one or add the new one to the bundle and then remove the
revoked certificate so as not to break anything.
Any help is appreciated. I am not strong with certificates so the more
detail you can give the better.
Thank you.
You say it was running with the self signed IPA CA and than GoDaddy cert
was added to the bundle. How was it added?
IPA does not use certs for communication between the instances. It uses
Kerberos. I am not sure the DoDaddy cert you added is even used in some way
by IPA.
It seems that your GoDaddy cert is an orthogonal trust so if you replaced
the main key pair then you just need to distribute your new GoDaddy cert to
the clients as you did on the first place.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Dmitri Pal
2015-03-13 18:15:25 UTC
Permalink
Post by Dmitri Pal
IPA does not use certs for communication between the instances. It
uses Kerberos. I am not sure the DoDaddy cert you added is even
used in some way by IPA.
Could you explain what the various uses of the IPA certs are, then?
AFAICT, the IPA masters generate a certificate for each node in the
- Webui/api (apache) communication over https.
- LDAP binding/communication over 636 (TLS).
Rob would definitely know more but IPA mostly provides certs for the
infra it serves and has a limited use of the certs by itself.
So here is where I know it is used:
- You can issue certs for hosts and services and installer used to
create certs for host automatically though these certs are not used for
anything and we decided not to create them automatically any more.
- You need to trust IPA in browser so that you can do a forms based
authentication if you do not have a kerberos ticket.
- To issue certs we use Dogtag and Dogtag understands only cert based
authentication so internally the communication between the managment
framework and Dogtag uses SSL. This is actually why the host-del fails.
The host had a cert issued by IPA CA so as part of the del operation it
tries to revoke the cert but since you reconfigured the sustem to use be
CA less it can't and fails.

The communication between the LDAP servers is Kerberos authenticated.
Post by Dmitri Pal
But if the certs are not utilized for communication between the
instances (per statement above), what are they used for?
I'm not hijacking the thread, I'm actually in the exact same position
as OP. I replaced the self-signed IPA/dogtag CA root with one that was
signed by our own CA and am now having problems with various cert
errors during client enrollment or any other similar activity (like
doing an 'ipa host-del' directly on an IPA master).
We have a special tool in Freeipa 4.2 to do this. The manual procedure
is cumbersome and leads to issues like this.
Post by Dmitri Pal
I can post those details in a separate thread, but before I go down
that path, I want to better understand what the purpose of the certs
are so I can deterine what's the best path forward for us.
As I understand it from the docs, there are three primary ways to run
- self-signed IPA CA, this is the default
- signing the IPA CA root with an "external"/3rd-party CA
- running "CA-less" and providing all certs with the
external/3rd-party CA (depending on what the use/purpose of the certs
are, this is increasingly becoming an attractive option but is likely
also tedious in its own right)
You are correct here.
Post by Dmitri Pal
Thanks for any insight.
Post by sipazzo
Good afternoon, we have a freeipa 3.0.42 installation running on
redhead 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It
was originally configured with the built in dogtag certificate CA
and then one of my co-workers added our GoDaddy certificate to
the certificate bundle. My understanding is this cert is used for
communication between the ipa servers as well as the clients are
also configured to trust the GoDaddy certificate. We recently had
to get a new GoDaddy cert so our old one is revoked. I need to
figure out how to either replace the existing revoked cert with
the new one or add the new one to the bundle and then remove the
revoked certificate so as not to break anything.
Any help is appreciated. I am not strong with certificates so the
more detail you can give the better.
Thank you.
You say it was running with the self signed IPA CA and than
GoDaddy cert was added to the bundle. How was it added?
IPA does not use certs for communication between the instances. It
uses Kerberos. I am not sure the DoDaddy cert you added is even
used in some way by IPA.
It seems that your GoDaddy cert is an orthogonal trust so if you
replaced the main key pair then you just need to distribute your
new GoDaddy cert to the clients as you did on the first place.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
Johnny Tan
2015-03-13 18:51:20 UTC
Permalink
Post by Dmitri Pal
Rob would definitely know more but IPA mostly provides certs for the
infra it serves and has a limited use of the certs by itself.
- You can issue certs for hosts and services and installer used to create
certs for host automatically though these certs are not used for anything
and we decided not to create them automatically any more.
- You need to trust IPA in browser so that you can do a forms based
authentication if you do not have a kerberos ticket.
- To issue certs we use Dogtag and Dogtag understands only cert based
authentication so internally the communication between the managment
framework and Dogtag uses SSL. This is actually why the host-del fails. The
host had a cert issued by IPA CA so as part of the del operation it tries
to revoke the cert but since you reconfigured the sustem to use be CA less
it can't and fails.
The communication between the LDAP servers is Kerberos authenticated.
I'll wait for Rob to weigh in, but wow, this would actually be huge for us
and probably a lot of other users. Because if the above is true (and
complete, I guess), then we could actually just run a CA-less FreeIPA
setup, and then generate certs specifically and only for the web (apache)
side, which is easy enough and we do it already for all other internal web
services. That limits cert-related stuff to just one web SSL cert per IPA
master.
Post by Dmitri Pal
We have a special tool in Freeipa 4.2 to do this. The manual procedure is
cumbersome and leads to issues like this.
Yeah, I saw that, but we are still doing 3.0 on CentOS6.6, which is why we
had to go down the manual path.

Thanks,
johnny
Dmitri Pal
2015-03-13 19:42:16 UTC
Permalink
Post by Dmitri Pal
Rob would definitely know more but IPA mostly provides certs for
the infra it serves and has a limited use of the certs by itself.
- You can issue certs for hosts and services and installer used to
create certs for host automatically though these certs are not
used for anything and we decided not to create them automatically
any more.
- You need to trust IPA in browser so that you can do a forms
based authentication if you do not have a kerberos ticket.
- To issue certs we use Dogtag and Dogtag understands only cert
based authentication so internally the communication between the
managment framework and Dogtag uses SSL. This is actually why the
host-del fails. The host had a cert issued by IPA CA so as part of
the del operation it tries to revoke the cert but since you
reconfigured the sustem to use be CA less it can't and fails.
The communication between the LDAP servers is Kerberos authenticated.
I'll wait for Rob to weigh in, but wow, this would actually be huge
for us and probably a lot of other users. Because if the above is true
(and complete, I guess), then we could actually just run a CA-less
FreeIPA setup, and then generate certs specifically and only for the
web (apache) side, which is easy enough and we do it already for all
other internal web services. That limits cert-related stuff to just
one web SSL cert per IPA master.
This is up to you but that means you would not be able to deal with SSL
for some other use cases down the road.
IPA 4.2 has a lot of new functionality to make it easier to issue and
manage certificates for different use cases like: system provisioning,
VPN, devices, wireless, PaaS/IaaS stacks that use certs for SSL
internally etc. Going CA-less will prevent you from leveraging these
capabilities once you realize they are needed down the road.

May be you would not need them but I would encourage you to look at this
in a longer perspective than just immediate needs.
Post by Dmitri Pal
We have a special tool in Freeipa 4.2 to do this. The manual
procedure is cumbersome and leads to issues like this.
And to be correct it is in 4.1 and already released. Sorry for typo.
Post by Dmitri Pal
Yeah, I saw that, but we are still doing 3.0 on CentOS6.6, which is
why we had to go down the manual path.
Thanks,
johnny
--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
Rob Crittenden
2015-03-13 20:44:07 UTC
Permalink
Post by Dmitri Pal
Rob would definitely know more but IPA mostly provides certs for the
infra it serves and has a limited use of the certs by itself.
- You can issue certs for hosts and services and installer used to
create certs for host automatically though these certs are not used
for anything and we decided not to create them automatically any more.
- You need to trust IPA in browser so that you can do a forms based
authentication if you do not have a kerberos ticket.
- To issue certs we use Dogtag and Dogtag understands only cert
based authentication so internally the communication between the
managment framework and Dogtag uses SSL. This is actually why the
host-del fails. The host had a cert issued by IPA CA so as part of
the del operation it tries to revoke the cert but since you
reconfigured the sustem to use be CA less it can't and fails.
The communication between the LDAP servers is Kerberos authenticated.
I'll wait for Rob to weigh in, but wow, this would actually be huge for
us and probably a lot of other users. Because if the above is true (and
complete, I guess), then we could actually just run a CA-less FreeIPA
setup, and then generate certs specifically and only for the web
(apache) side, which is easy enough and we do it already for all other
internal web services. That limits cert-related stuff to just one web
SSL cert per IPA master.
We have a special tool in Freeipa 4.2 to do this. The manual
procedure is cumbersome and leads to issues like this.
Yeah, I saw that, but we are still doing 3.0 on CentOS6.6, which is why
we had to go down the manual path.
The CA-less install was improved in IPA 3.3. It can sorta work in 3.0
but it will be bumpy. A number of bugs were fixed in
ipa-server-certinstall, the tool used to replace the IPA certs with
user-provided certs. Or you can pass in PKCS#12 files during the install
but the root CA is implicit in that case so you need to be careful in
creating the file.

You still need an SSL cert for LDAP as well. SSL is used to bootstrap
replication when a new master is set up. When that is done the agreement
is converted to using GSSAPI.

The clients (depending on version) will still ask for a host cert on
install but it is generally treated as a non-fatal error if one isn't
obtained.

Otherwise it should work, but as Dmitri points out you are limiting
yourself upgrade-wise. The only migration paths from one version of IPA
to another is replication, in which case you still wouldn't be able to
add a CA, or via the LDAP migration routines which only migrate users
and groups currently.

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
Johnny Tan
2015-03-13 21:06:14 UTC
Permalink
Post by Rob Crittenden
The CA-less install was improved in IPA 3.3. It can sorta work in 3.0
but it will be bumpy. A number of bugs were fixed in
ipa-server-certinstall, the tool used to replace the IPA certs with
user-provided certs. Or you can pass in PKCS#12 files during the install
but the root CA is implicit in that case so you need to be careful in
creating the file.
You still need an SSL cert for LDAP as well. SSL is used to bootstrap
replication when a new master is set up. When that is done the agreement
is converted to using GSSAPI.
Aha, I was about to ask about this since a CA-less install still requires
dirsrv cert. Thanks.
Post by Rob Crittenden
The clients (depending on version) will still ask for a host cert on
install but it is generally treated as a non-fatal error if one isn't
obtained.
Was also going to ask about this since the v3 CA-less wiki page mentions
the need to obtain host certs but is not very clear about what it was used
for.
Post by Rob Crittenden
Otherwise it should work, but as Dmitri points out you are limiting
yourself upgrade-wise. The only migration paths from one version of IPA
to another is replication, in which case you still wouldn't be able to
add a CA, or via the LDAP migration routines which only migrate users
and groups currently.
Not being able to do the upgrade easily will definitely be a showstopper.
Ok, I'm going to go back to attempting to sign the IPA CA with our own,
then, and I'll open a separate thread if that doesn't work. I may just
start from scratch with that.

Thank you Dmitri and Rob for the clear/concise info.

johnny
sipazzo
2015-03-13 20:32:27 UTC
Permalink
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 <***@yahoo.com>
To: Rob Crittenden <***@redhat.com>
Cc: "freeipa-***@redhat.com" <freeipa-***@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-***@redhat.com [mailto:freeipa-users-***@redhat.com] On Behalf Of Rob Crittenden
Sent: Thursday, March 12, 2015 1:52 PM
To: sipazzo; freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers
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/***@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/***@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-----
Sent: Wednesday, March 11, 2015 7:20 PM
Subject: Re: [Freeipa-users] Need to replace cert for ipa servers
Thanks Rob, I apologize that error was probably not helpful. This is
Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an
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
--
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
sipazzo
2015-03-24 20:20:42 UTC
Permalink
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-***@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 <***@yahoo.com>
To: Rob Crittenden <***@redhat.com>; "freeipa-***@redhat.com" <freeipa-***@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 <***@yahoo.com>
To: Rob Crittenden <***@redhat.com>
Cc: "freeipa-***@redhat.com" <freeipa-***@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-***@redhat.com [mailto:freeipa-users-***@redhat.com] On Behalf Of Rob Crittenden
Sent: Thursday, March 12, 2015 1:52 PM
To: sipazzo; freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers
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/***@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/***@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-----
Sent: Wednesday, March 11, 2015 7:20 PM
Subject: Re: [Freeipa-users] Need to replace cert for ipa servers
Thanks Rob, I apologize that error was probably not helpful. This is
Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an
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
--
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
Rob Crittenden
2015-03-25 21:43:52 UTC
Permalink
Post by sipazzo
Ok I finally was able to get a sandbox environment up to test the cert
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
I got a message saying the cert at same location is already used by
request with nickname "20140729215511" , same when I ran it for
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
Post by sipazzo
# certutil -V -u V -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM
PR_FILE_NOT_FOUND_ERROR: File not found
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.
------------------------------------------------------------------------
*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.
------------------------------------------------------------------------
*Sent:* Friday, March 13, 2015 9:21 AM
*Subject:* Re: [Freeipa-users] Fw: Need to replace cert for ipa servers
-----Original Message-----
Sent: Thursday, March 12, 2015 1:52 PM
Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers
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
# ipa-getcert request -d /etc/httpd/alias -n Server-Cert -p
/etc/httpd/alias/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_httpd
# 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
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
# 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
# certutil -A -n 'IPA CA' -d /etc/pki/nssdb -t CT,C,C -a -i /etc/ipa/ca.crt
# certutil -V -u V -n Server-Cert -d /etc/httpd/alias # certutil -V -u V
-n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM
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
# 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-----
Sent: Wednesday, March 11, 2015 7:20 PM
Subject: Re: [Freeipa-users] Need to replace cert for ipa servers
Thanks Rob, I apologize that error was probably not helpful. This is
Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an
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
--
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
--
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
sipazzo
2015-03-27 22:42:02 UTC
Permalink
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 <***@redhat.com> wrote:

Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers
To: "sipazzo" <***@yahoo.com>, "freeipa-***@redhat.com" <freeipa-***@redhat.com>
Date: Wednesday, March 25, 2015, 2:43 PM
Post by sipazzo
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
Post by sipazzo
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
Post by sipazzo
I got a message
saying the cert at same location is already used by
Post by sipazzo
request with nickname
"20140729215511" , same when I ran it for
Post by sipazzo
/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
Post by sipazzo
  # certutil -V -u V -n Server-Cert -d
/etc/dirsrv/slapd-EXAMPLE-COM
certutil: could not find certificate named
"Server-Cert":
PR_FILE_NOT_FOUND_ERROR: File not found
Post by sipazzo
Although running certutil -L -d
/etc/dirsrv/slapd-IPADOMAIN-COM/,
returns this:
Certificate Nickname                         
               Trust
Attributes
Post by sipazzo
                   
                                     
   
Post by sipazzo
SSL,S/MIME,JAR/XPI
GD_CA         
                                       
      CT,C,C
Post by sipazzo
IPADOMAIN.COM IPA CA 
                                   
CT,,
Post by sipazzo
NWF_GD                 
                                 
   u,u,u
Post by sipazzo
Showing that the IPA
Dogtag cert is now listed whereas it was not
Post by sipazzo
previously.
------------------------------------------------------------------------
Post by sipazzo
*Sent:* Friday, March 13, 2015 1:32 PM
*Subject:* Re: [Freeipa-users] Fw: Need to
replace cert for ipa servers
Post by sipazzo
This environment is over 350 servers, many
of which are in production so
Post by sipazzo
I may
have to wait a bit for change management approval to attempt
to
Post by sipazzo
resolve this issue, particularly if
you think it might break something.
Post by sipazzo
I
will keep you updated on my progress. Thank you much.
------------------------------------------------------------------------
Post by sipazzo
*Sent:* Friday, March 13, 2015 9:21 AM
*Subject:* Re: [Freeipa-users] Fw: Need to
replace cert for ipa servers
Post by sipazzo
-----Original Message-----
On Behalf Of Rob Crittenden
Thursday, March 12, 2015 1:52 PM
Post by sipazzo
Subject: Re: [Freeipa-users] Fw: Need to
replace cert for ipa servers
Post by sipazzo
I
do have other CAs (just not the master but it is available
offline
Post by sipazzo
if
needed)
Post by sipazzo
To be
clear, all IPA servers are masters, some just run more
services
Post by sipazzo
than others. It sounds like
you have at least one CA available which
Post by sipazzo
should be sufficient.
Directory server is running
The apache web server is running and I
can get to the gui ipa
Post by sipazzo
cert-show 1
works
Post by sipazzo
Ok. I guess
the place to start is to get certs for Apache and 389-ds,
Post by sipazzo
then we can see about using these new
certs.
Post by sipazzo
In the
thread you showed that the IPA 389-ds doesn't have a
Server-Cert
Post by sipazzo
nickname. You'll want
to do the same for /etc/httpd/alias before running
Post by sipazzo
the following commands otherwise you could
end up with non-functional
Post by sipazzo
server.
These should get IPA
certs for 389-ds and Apache. You'll need to edit
Post by sipazzo
these commands to match your
#
ipa-getcert request -d /etc/httpd/alias -n Server-Cert -p
Post by sipazzo
/etc/httpd/alias/pwdfile.txt -C
/usr/lib64/ipa/certmonger/restart_httpd
Post by sipazzo
# 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
Post by sipazzo
CN=ipa.example.com
I'd do them one
at a time and wait until the cert is issued and tracked.
Post by sipazzo
This will restart both Apache and 389-ds
but it shouldn't affect
Post by sipazzo
operation
because the certs won't be used yet.
Post by sipazzo
You then need to get
the old CA cert and put it into the right places.
Post by sipazzo
Since it is already in the PKI-IPA NSS
database let's fetch it from
Post by sipazzo
there.
For giggles you should probably save whatever the contents
of
Post by sipazzo
/etc/ipa/ca.crt are before-hand.
# certutil -L -d
/etc/dirsrv/slapd-PKI-IPA -n 'IPADOMAIN.COM IPA CA'
-a
Post by sipazzo
/etc/ipa/ca.crt
Now add that to the
# 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
Post by sipazzo
# certutil
-A -n 'IPA CA' -d /etc/pki/nssdb -t CT,C,C -a -i
/etc/ipa/ca.crt
Post by sipazzo
# certutil -V -u V
-n Server-Cert -d /etc/httpd/alias # certutil -V -u V
Post by sipazzo
-n Server-Cert -d
/etc/dirsrv/slapd-EXAMPLE-COM
certutil: certificate is valid
Post by sipazzo
Next is to configure the services to use
the new certs. I'd stop IPA to
Post by sipazzo
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
Post by sipazzo
to Server-Cert
Now try to start the
world: ipactl start
Post by sipazzo
# 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
Post by sipazzo
Finally run: ipa-ldap-updater --upgrade
This should load the
new CA certificate into LDAP.
Post by sipazzo
This has the potential to break a whole
bunch of your clients. It is
Post by sipazzo
probably
enough to just copy over the new CA cert to the right
Post by sipazzo
location(s) on the clients. The mechanics
of this depend on the OS.
Post by sipazzo
Are the TLS errors due to the mismatch
in certs between slapd-PKI-CA
Post by sipazzo
and
slapd-NETWORKFLEET-COM?
Post by sipazzo
No, has nothing to do with the CA at all.
The client doesn't have (or
Post by sipazzo
trust)
the CA that issued the LDAP server cert.
Post by sipazzo
rob
-----Original
Message-----
On Behalf Of Rob Crittenden
Wednesday, March 11, 2015 7:20 PM
Post by sipazzo
Subject: Re: [Freeipa-users] Need to
replace cert for ipa servers
Post by sipazzo
Thanks Rob, I apologize that error
was probably not helpful. This is
Post by sipazzo
what I see when running install in
Verifying that
ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an
Post by sipazzo
IPA server Init LDAP connection
with:
ldap://ipa2-corp.networkfleet.com:389
Post by sipazzo
LDAP Error: Connect error: TLS
error -8179:Peer's Certificate issuer
Post by sipazzo
is not recognized.
Verifying that
ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA
ldap://ipa1-xo.networkfleet.com:389
Post by sipazzo
LDAP Error: Connect error: TLS
error -8179:Peer's Certificate issuer
Post by sipazzo
is not recognized.
Verifying that
ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA
ldap://ipa1-io.networkfleet.com:389
Post by sipazzo
LDAP Error: Connect error: TLS
error -8179:Peer's Certificate issuer
Post by sipazzo
is not recognized.
Verifying that
ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA
ldap://ipa2-io.networkfleet.com:389
Post by sipazzo
LDAP Error: Connect error: TLS
error -8179:Peer's Certificate issuer
Post by sipazzo
is not recognized.
Verifying that
ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA
ldap://ipa2-xo.networkfleet.com:389
Post by sipazzo
LDAP Error: Connect error: TLS
error -8179:Peer's Certificate issuer
Post by sipazzo
is not recognized.
The
certificates are very confusing to me. I don't
understand how
Post by sipazzo
things are
working when we have a set of GoDaddy certs in
Post by sipazzo
slapd-NETWORKFLEET-COM and a set
of the Dogtag certs in slapd-PKI-CA.
Post by sipazzo
The cert in
/usr/share/ipa/html/ca.crt looks like the original one
Post by sipazzo
issued by the Dogtag cert system
and matches the ones on the clients.
Post by sipazzo
Not to further confuse things but
the original master server that
signed all these certs was taken offline months ago due to
some
Post by sipazzo
issues it was having. I do
still have access to it if necessary.
Post by sipazzo
As
far as why the godaddy certs were swapped out for the Dogtag
certs
Post by sipazzo
it was originally for
something as simple as the untrusted
Post by sipazzo
certificate dialogue when
accessing the ipa gui. I did not swap out
Post by sipazzo
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
Post by sipazzo
the best solution to
the issues I am seeing as I am in kind of a bind
Post by sipazzo
with the GoDaddy cert being
revoked and needing to be replaced and
Post by sipazzo
the master Dogtag certificate
server offline. We have a mixed
environment with Rhel 5, 6 and Solaris clients so are not
using sssd
Post by sipazzo
in all cases.
I
know this is asking a lot but appreciate any help you can
give.
Post by sipazzo
What
is the current state of things? Does your IPA Apache server
work?
Post by sipazzo
Is 389-ds up and running? Do
you have a working IPA CA?
Post by sipazzo
Does ipa cert-show 1 work?
If the answer
is yes to all then we should be able to generate new
Post by sipazzo
certs for all the services.
rob
--
Manage
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
Post by sipazzo
--
Manage your
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
Loading...