Hi folks,
Platform: Centos 7.4, ipa 4.5.0-21
The ipa service cannot be started anymore. Error message:
# systemctl status ipa * ipa.service - Identity, Policy, Audit Loaded: loaded (/usr/lib/systemd/system/ipa.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2017-12-06 14:45:53 CET; 12min ago Process: 307 ExecStart=/usr/sbin/ipactl start (code=exited, status=1/FAILURE) Main PID: 307 (code=exited, status=1/FAILURE)
Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting Directory Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting krb5kdc Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting kadmin Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting httpd Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting ipa-custodia Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting pki-tomcatd Service Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: ipa.service: main process exited, code=exited, status=1/FAILURE Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: Failed to start Identity, Policy, Audit. Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: Unit ipa.service entered failed state. Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: ipa.service failed.
Apparently pki-tomcatd is to blame. See the attached logfiles.
Every helpful comment is highly appreciated. Harri
Harald Dunkel via FreeIPA-users wrote:
Hi folks,
Platform: Centos 7.4, ipa 4.5.0-21
The ipa service cannot be started anymore. Error message:
# systemctl status ipa
- ipa.service - Identity, Policy, Audit Loaded: loaded (/usr/lib/systemd/system/ipa.service; enabled; vendor
preset: disabled) Active: failed (Result: exit-code) since Wed 2017-12-06 14:45:53 CET; 12min ago Process: 307 ExecStart=/usr/sbin/ipactl start (code=exited, status=1/FAILURE) Main PID: 307 (code=exited, status=1/FAILURE)
Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting Directory Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting krb5kdc Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting kadmin Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting httpd Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting ipa-custodia Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting pki-tomcatd Service Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: ipa.service: main process exited, code=exited, status=1/FAILURE Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: Failed to start Identity, Policy, Audit. Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: Unit ipa.service entered failed state. Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: ipa.service failed.
Apparently pki-tomcatd is to blame. See the attached logfiles.
Need the (compressed) debug log.
You can get the rest of the IPA service started by passing --ignore-service-failures to ipactl.
rob
See attachment.
Please note the "invalid certificate". Du you remember the thread on freeipa-devel about "ipa-client-install (3.0.2 on Wheezy) fails after root certificate change via ipa-cacert-manage" and the output of "ipa-certupdate -v" I had posted?
Regards Harri
Harald Dunkel via FreeIPA-users wrote:
See attachment.
Please note the "invalid certificate". Du you remember the thread on freeipa-devel about "ipa-client-install (3.0.2 on Wheezy) fails after root certificate change via ipa-cacert-manage" and the output of "ipa-certupdate -v" I had posted?
The ipa-certupdate error was a red herring. IPA was just looking for all possible CA certs it could know about.
It does look like the trust is wrong on your CA cert in the tomcat NSS database.
# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias [ snip ] caSigningCert cert-pki-ca CTu,Cu,Cu
If yours isn't that you can try modifying it with:
# certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "caSigningCert cert-pki-ca" -t CTu,Cu,Cu
rob
Hi Rob,
On 12/06/17 17:39, Rob Crittenden via FreeIPA-users wrote:
Harald Dunkel via FreeIPA-users wrote:
See attachment.
Please note the "invalid certificate". Du you remember the thread on freeipa-devel about "ipa-client-install (3.0.2 on Wheezy) fails after root certificate change via ipa-cacert-manage" and the output of "ipa-certupdate -v" I had posted?
The ipa-certupdate error was a red herring. IPA was just looking for all possible CA certs it could know about.
OK.
It does look like the trust is wrong on your CA cert in the tomcat NSS database.
# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias [ snip ] caSigningCert cert-pki-ca CTu,Cu,Cu
If yours isn't that
Sorry, but I don't understand. My what isn't what?
you can try modifying it with:
# certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "caSigningCert cert-pki-ca" -t CTu,Cu,Cu
Here is what I see on the broken ipa server:
[root@ipa1 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ,,
The CN=example Root CA,... certificate is unwanted. It did not expire, but it uses an invalid format for its expiration date. I ran ipa-cacert-manage to replace it with the CN=root-CA,... certificate a few months ago.
The certificate database on another ipa server (not broken yet, as it seems) looks different:
[root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-ca CTu,Cu,Cu CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u
I would highly appreciate any advice how to cleanup this mess.
How comes that the unwanted "example Root CA" is still in the databases at all? Due to the broken format I have to get rid of it asap.
Regards Harri
Harald Dunkel via FreeIPA-users wrote:
Hi Rob,
On 12/06/17 17:39, Rob Crittenden via FreeIPA-users wrote:
Harald Dunkel via FreeIPA-users wrote:
See attachment.
Please note the "invalid certificate". Du you remember the thread on freeipa-devel about "ipa-client-install (3.0.2 on Wheezy) fails after root certificate change via ipa-cacert-manage" and the output of "ipa-certupdate -v" I had posted?
The ipa-certupdate error was a red herring. IPA was just looking for all possible CA certs it could know about.
OK.
It does look like the trust is wrong on your CA cert in the tomcat NSS database.
# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias [ snip ] caSigningCert cert-pki-ca CTu,Cu,Cu
If yours isn't that
Sorry, but I don't understand. My what isn't what?
If your entry doesn't look like that, which it does.
you can try modifying it with:
# certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "caSigningCert cert-pki-ca" -t CTu,Cu,Cu
Here is what I see on the broken ipa server:
[root@ipa1 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ,,
The CN=example Root CA,... certificate is unwanted. It did not expire, but it uses an invalid format for its expiration date. I ran ipa-cacert-manage to replace it with the CN=root-CA,... certificate a few months ago.
The certificate database on another ipa server (not broken yet, as it seems) looks different:
[root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-ca CTu,Cu,Cu CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u
I would highly appreciate any advice how to cleanup this mess.
How comes that the unwanted "example Root CA" is still in the databases at all? Due to the broken format I have to get rid of it asap.
What is broken about the cert? I can only assume you installed your IPA server by having an external CA sign it. It would appear that this external CA, in your case CN=root-ca, isn't trusted hence the server won't start.
To fix this you could run:
# certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE" -t C,,
rob
Hi Rob,
On 12/6/17 9:56 PM, Rob Crittenden via FreeIPA-users wrote:
Harald Dunkel via FreeIPA-users wrote:
Here is what I see on the broken ipa server:
[root@ipa1 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ,,
The CN=example Root CA,... certificate is unwanted. It did not expire, but it uses an invalid format for its expiration date. I ran ipa-cacert-manage to replace it with the CN=root-CA,... certificate a few months ago.
The certificate database on another ipa server (not broken yet, as it seems) looks different:
[root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-ca CTu,Cu,Cu CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u
I would highly appreciate any advice how to cleanup this mess.
How comes that the unwanted "example Root CA" is still in the databases at all? Due to the broken format I have to get rid of it asap.
What is broken about the cert? I can only assume you installed your IPA server by having an external CA sign it. It would appear that this external CA, in your case CN=root-ca, isn't trusted hence the server won't start.
The first ipa server was setup using an existing private PKI, managed outside of freeipa. The root ca cert had a problem I noticed too late: It uses an invalid format for the notAfter attribute. openssl is fine with this format, but libressl on OpenBSD (and probably MacOS) rejects it. See this thread for more information:
https://marc.info/?l=libressl&m=148939571912276&w=2
Point is, I had to create a new private PKI with a valid notAfter attribute format, and to tell freeipa. I had used ipa-cacert-manage to fix, following the guidelines on https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
ipa-cacert-manage renew --external-ca : ipa-cacert-manage renew --external-cert-file=/tmp/cert.pem --external-cert-file=/tmp/cacert.pem ipa-certupdate : getcert list getcert list | egrep Request|CA|issuer|subject|expires : ipa-getcert resubmit -i $request_id :
So how comes that the new root certificate is not trusted?
To fix this you could run:
# certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE" -t C,,
Done. ipa1 starts again. But this is not sufficient. If I run ipa-certupdate, then the database is set back to the bad state. /etc/ipa/ca.crt and /usr/share/ipa/html/ca.crt are still bad, too.
???
Regards Harri
PS: I have derived another CA replica "ipa0" from ipa2. certutil shows different trustargs again. Shouldn't ipa2 and the new ipa0 have identical trustargs?
[root@ipa0 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u Server-Cert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-ca CTu,Cu,Cu ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu
ipa2 has:
[root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-ca CTu,Cu,Cu CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u
Regards Harri
On 12/07/2017 09:17 AM, Harald Dunkel via FreeIPA-users wrote:
Hi Rob,
On 12/6/17 9:56 PM, Rob Crittenden via FreeIPA-users wrote:
Harald Dunkel via FreeIPA-users wrote:
Here is what I see on the broken ipa server:
[root@ipa1 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ,,
The CN=example Root CA,... certificate is unwanted. It did not expire, but it uses an invalid format for its expiration date. I ran ipa-cacert-manage to replace it with the CN=root-CA,... certificate a few months ago.
The certificate database on another ipa server (not broken yet, as it seems) looks different:
[root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C caSigningCert cert-pki-ca CTu,Cu,Cu CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,, ocspSigningCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u
I would highly appreciate any advice how to cleanup this mess.
How comes that the unwanted "example Root CA" is still in the databases at all? Due to the broken format I have to get rid of it asap.
What is broken about the cert? I can only assume you installed your IPA server by having an external CA sign it. It would appear that this external CA, in your case CN=root-ca, isn't trusted hence the server won't start.
The first ipa server was setup using an existing private PKI, managed outside of freeipa. The root ca cert had a problem I noticed too late: It uses an invalid format for the notAfter attribute. openssl is fine with this format, but libressl on OpenBSD (and probably MacOS) rejects it. See this thread for more information:
https://marc.info/?l=libressl&m=148939571912276&w=2
Point is, I had to create a new private PKI with a valid notAfter attribute format, and to tell freeipa. I had used ipa-cacert-manage to fix, following the guidelines on https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
ipa-cacert-manage renew --external-ca : ipa-cacert-manage renew --external-cert-file=/tmp/cert.pem --external-cert-file=/tmp/cacert.pem ipa-certupdate : getcert list getcert list | egrep Request|CA|issuer|subject|expires : ipa-getcert resubmit -i $request_id :
So how comes that the new root certificate is not trusted?
Hi,
if you run:
ipa-cacert-manage install -t C,, <rootcert> ipa-certupdate
then the new root certificate will be installed in all the required NSS databases. Do not forget to run ipa-certupdate on all the FreeIPA machines.
HTH, Flo.
To fix this you could run:
# certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n "CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE" -t C,,
Done. ipa1 starts again. But this is not sufficient. If I run ipa-certupdate, then the database is set back to the bad state. /etc/ipa/ca.crt and /usr/share/ipa/html/ca.crt are still bad, too.
???
Regards Harri _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On 12/7/17 2:53 PM, Florence Blanc-Renaud wrote:
Hi,
if you run:
ipa-cacert-manage install -t C,, <rootcert> ipa-certupdate
then the new root certificate will be installed in all the required NSS databases. Do not forget to run ipa-certupdate on all the FreeIPA machines.
This did not work:
[root@ipa1 ~]# ipa-cacert-manage install -t C,, pki2/root-ca.crt Installing CA certificate, please wait Not a valid CA certificate: (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user. (visit http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) The ipa-cacert-manage command failed.
Regards Harri
Harald, Maybe in the ldap certificate container you already have the same certificate you're trying to install, but it has another key or untrusted? Then try to delete it via ldapdelete and certutil -d and then try again install new one.
2017-12-07 17:20 GMT+03:00 Harald Dunkel via FreeIPA-users < freeipa-users@lists.fedorahosted.org>:
On 12/7/17 2:53 PM, Florence Blanc-Renaud wrote:
Hi,
if you run:
ipa-cacert-manage install -t C,, <rootcert> ipa-certupdate
then the new root certificate will be installed in all the required NSS databases. Do not forget to run ipa-certupdate on all the FreeIPA machines.
This did not work:
[root@ipa1 ~]# ipa-cacert-manage install -t C,, pki2/root-ca.crt Installing CA certificate, please wait Not a valid CA certificate: (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user. (visit http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) The ipa-cacert-manage command failed.
Regards Harri _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi Flo and Andrew,
thanx for you replies, but I think you missed the point:
The new (external) root CA certificate and the new ipa CA certificate are *in* freeipa already, but on the host I had used for running ipa-cacert-manage to deploy this new PKI the database in /var/lib/pki/pki-tomcat/ca/alias appears to be in an inconsistent state. Manually fixing this is not persistent.
If I create another CA replica, then this server looks fine, except for the old root CA still in /etc/ipa/ca.crt .
I would like to get rid of the old PKI completely.
Regards Harri
On 12/08/2017 08:01 AM, Harald Dunkel via FreeIPA-users wrote:
Hi Flo and Andrew,
thanx for you replies, but I think you missed the point:
The new (external) root CA certificate and the new ipa CA certificate are *in* freeipa already, but on the host I had used for running ipa-cacert-manage to deploy this new PKI the database in /var/lib/pki/pki-tomcat/ca/alias appears to be in an inconsistent state. Manually fixing this is not persistent.
If I create another CA replica, then this server looks fine, except for the old root CA still in /etc/ipa/ca.crt .
I would like to get rid of the old PKI completely.
Regards Harri _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi Harald,
the external CAs and FreeIPA CA must be stored in the LDAP server (cn=certificates,cn=ipa,cn=etc,$BASEDN). The correct procedure to add external CAs to the LDAP server is to run ipa-cacert-manage install.
You need first to have a clean state in the LDAP server. When all the required CAs are stored in LDAP with the right trust attribute, you can use ipa-certupdate to retrieve them and place them in the NSS databases and /etc/ipa/ca.crt.
If some certificates are manually added to the NSS databases but not present in the LDAP server, the next call to ipa-certupdate will remove them, this is why the state is not persistent.
If you want to completely remove an old root CA, you need to delete it from the LDAP server otherwise it will return on next call to ipa-certupdate.
Hope this clarifies, Flo.
Hi Flo,
On 12/8/17 10:52 AM, Florence Blanc-Renaud wrote:
Hi Harald,
the external CAs and FreeIPA CA must be stored in the LDAP server (cn=certificates,cn=ipa,cn=etc,$BASEDN). The correct procedure to add external CAs to the LDAP server is to run ipa-cacert-manage install.
ACK
You need first to have a clean state in the LDAP server. When all the required CAs are stored in LDAP with the right trust attribute, you can use ipa-certupdate to retrieve them and place them in the NSS databases and /etc/ipa/ca.crt.
The ipa Servers ipa1 and ipa2 are in sync, as reported by ipa-replica-manage and ipa-csreplica-manage.
jxplorer shows me 3 certificates:
- the ipa ca certificate signed by the new root CA - the old root CA certificate "cn=example Root CA, ..." - the new root CA certificate "cn=root-CA, ..."
The old root CA certificate has much more attributes set than the new one, esp. there is an attribute ipaKeyTrust set to "trusted", and several other ipaKeyExtUsage attributes not set for the new root CA certificate. Attached you can find the output of ldapsearch for cn=certificates.
As you suggested, I used ipa-certupdate to deploy the new PKI, but I wonder if the attributes for the new root CA certificate are set correctly? Please note the "ipaKeyExtUsage: 1.3.6.1.4.1.3319.6.10.16" set only for the new root CA cert.
Looking into the old and new root CA certs I see very similar x509v3 extensions. Do you think the new root certificate could be bad internally?
If some certificates are manually added to the NSS databases but not present in the LDAP server, the next call to ipa-certupdate will remove them, this is why the state is not persistent.
I highly appreciate this central location.
If you want to completely remove an old root CA, you need to delete it from the LDAP server otherwise it will return on next call to ipa-certupdate.
AFAIU it is necessary to fix the attributes of the new root CA certificate entry in LDAP first. Would you recommend to set the lost ipaKeyExtUsage attributes?
Regards Harri
On 12/08/2017 01:08 PM, Harald Dunkel via FreeIPA-users wrote:
Hi Flo,
On 12/8/17 10:52 AM, Florence Blanc-Renaud wrote:
Hi Harald,
the external CAs and FreeIPA CA must be stored in the LDAP server (cn=certificates,cn=ipa,cn=etc,$BASEDN). The correct procedure to add external CAs to the LDAP server is to run ipa-cacert-manage install.
ACK
You need first to have a clean state in the LDAP server. When all the required CAs are stored in LDAP with the right trust attribute, you can use ipa-certupdate to retrieve them and place them in the NSS databases and /etc/ipa/ca.crt.
The ipa Servers ipa1 and ipa2 are in sync, as reported by ipa-replica-manage and ipa-csreplica-manage.
jxplorer shows me 3 certificates:
- the ipa ca certificate signed by the new root CA
- the old root CA certificate "cn=example Root CA, ..."
- the new root CA certificate "cn=root-CA, ..."
The old root CA certificate has much more attributes set than the new one, esp. there is an attribute ipaKeyTrust set to "trusted", and several other ipaKeyExtUsage attributes not set for the new root CA certificate. Attached you can find the output of ldapsearch for cn=certificates.
As you suggested, I used ipa-certupdate to deploy the new PKI, but I wonder if the attributes for the new root CA certificate are set correctly? Please note the "ipaKeyExtUsage: 1.3.6.1.4.1.3319.6.10.16" set only for the new root CA cert.
Looking into the old and new root CA certs I see very similar x509v3 extensions. Do you think the new root certificate could be bad internally?
If some certificates are manually added to the NSS databases but not present in the LDAP server, the next call to ipa-certupdate will remove them, this is why the state is not persistent.
I highly appreciate this central location.
If you want to completely remove an old root CA, you need to delete it from the LDAP server otherwise it will return on next call to ipa-certupdate.
AFAIU it is necessary to fix the attributes of the new root CA certificate entry in LDAP first. Would you recommend to set the lost ipaKeyExtUsage attributes?
Hi,
I would try to remove the new root CA from LDAP and re-import it using ipa-cacert-manage install -t C,, This should create the entry with the appropriate attributes.
Flo
Regards Harri
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi Flo,
On 12/08/17 15:36, Florence Blanc-Renaud via FreeIPA-users wrote:
Hi,
I would try to remove the new root CA from LDAP and re-import it using ipa-cacert-manage install -t C,, This should create the entry with the appropriate attributes.
Flo
Result: The new root CA certificate shows much better attributes in ldap:
dn: cn=CN\3Droot-CA\2COU\3Dexample Certificate Authority\2CO\3Dexample AG\2CC\3DDE,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1 cn: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE objectClass: ipaCertificate objectClass: pkiCA objectClass: ipaKeyPolicy objectClass: top ipaCertSubject: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ipaPublicKey:: MIICIjAN... cACertificate;binary:: MIIGDTCC... ipaKeyTrust: trusted ipaCertIssuerSerial: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE;1
A lot of ipaKeyExtUsage attributes appear to be missing, though, compared to the old root CA certificate. Is this expected?
ipa-certupdate failed:
# ipa-certupdate -v ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: Not logging to a file ipa: DEBUG: Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' ipa.ipaclient.plugins.rpcclient.rpcclient: INFO: trying https://ipa1.example.de/ipa/json ipa.ipaclient.plugins.rpcclient.rpcclient: DEBUG: Created connection context.rpcclient_54790992 ipa.ipaclient.plugins.rpcclient.rpcclient: INFO: [try 1]: Forwarding 'schema' to json server 'https://ipa1.example.de/ipa/json' ipa: DEBUG: New HTTP connection (ipa1.example.de) ipa: DEBUG: HTTP connection destroyed (ipa1.example.de) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in single_request self.get_auth_info() File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in get_auth_info self._handle_exception(e, service=service) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 578, in _handle_exception raise errors.TicketExpired() TicketExpired: Ticket expired ipa.ipaclient.plugins.rpcclient.rpcclient: DEBUG: Destroyed connection context.rpcclient_54790992 ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaclient/install/ipa_certupdate.py", line 57, in run api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 714, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 421, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 592, in load_plugins for package in self.packages: File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 948, in packages ipaclient.remote_plugins.get_package(self), File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", line 126, in get_package plugins = schema.get_package(server_info, client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 534, in get_package schema = Schema(client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 385, in __init__ fingerprint, ttl = self._fetch(client, ignore_cache=read_failed) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 409, in _fetch schema = client.forward(u'schema', **kwargs)['result'] File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1116, in forward return self._call_command(command, params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1092, in _call_command return command(*params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1246, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1213, in __request verbose=self.__verbose >= 3, File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in single_request self.get_auth_info() File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in get_auth_info self._handle_exception(e, service=service) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 578, in _handle_exception raise errors.TicketExpired()
ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: The ipa-certupdate command failed, exception: TicketExpired: Ticket expired ipa.ipaclient.install.ipa_certupdate.CertUpdate: ERROR: Ticket expired ipa.ipaclient.install.ipa_certupdate.CertUpdate: ERROR: The ipa-certupdate command failed.
Restarting ipa did not help. ???
Regards Harri
Hi folks,
any ideas about how to proceed? Is this bbr? Do I have to reactivate the old pki to get out of this mess?
Every helpful comment is highly appreciated. Harri
On 12/10/2017 10:58 AM, Harald Dunkel via FreeIPA-users wrote:
Hi Flo,
On 12/08/17 15:36, Florence Blanc-Renaud via FreeIPA-users wrote:
Hi,
I would try to remove the new root CA from LDAP and re-import it using ipa-cacert-manage install -t C,, This should create the entry with the appropriate attributes.
Flo
Result: The new root CA certificate shows much better attributes in ldap:
dn: cn=CN\3Droot-CA\2COU\3Dexample Certificate Authority\2CO\3Dexample AG\2CC\3DDE,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1 cn: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE objectClass: ipaCertificate objectClass: pkiCA objectClass: ipaKeyPolicy objectClass: top ipaCertSubject: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ipaPublicKey:: MIICIjAN... cACertificate;binary:: MIIGDTCC... ipaKeyTrust: trusted ipaCertIssuerSerial: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE;1
A lot of ipaKeyExtUsage attributes appear to be missing, though, compared to the old root CA certificate. Is this expected?
The ipaKeyExtUsage attribute is built from the trust flags provided to ipa-cacert-manage install, so it looks normal for me.
ipa-certupdate failed:
# ipa-certupdate -v ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: Not logging to a file ipa: DEBUG: Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' ipa.ipaclient.plugins.rpcclient.rpcclient: INFO: trying https://ipa1.example.de/ipa/json ipa.ipaclient.plugins.rpcclient.rpcclient: DEBUG: Created connection context.rpcclient_54790992 ipa.ipaclient.plugins.rpcclient.rpcclient: INFO: [try 1]: Forwarding 'schema' to json server 'https://ipa1.example.de/ipa/json' ipa: DEBUG: New HTTP connection (ipa1.example.de) ipa: DEBUG: HTTP connection destroyed (ipa1.example.de) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in single_request self.get_auth_info() File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in get_auth_info self._handle_exception(e, service=service) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 578, in _handle_exception raise errors.TicketExpired() TicketExpired: Ticket expired ipa.ipaclient.plugins.rpcclient.rpcclient: DEBUG: Destroyed connection context.rpcclient_54790992 ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaclient/install/ipa_certupdate.py", line 57, in run api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 714, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 421, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 592, in load_plugins for package in self.packages: File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 948, in packages ipaclient.remote_plugins.get_package(self), File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", line 126, in get_package plugins = schema.get_package(server_info, client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 534, in get_package schema = Schema(client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 385, in __init__ fingerprint, ttl = self._fetch(client, ignore_cache=read_failed) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 409, in _fetch schema = client.forward(u'schema', **kwargs)['result'] File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1116, in forward return self._call_command(command, params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1092, in _call_command return command(*params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1246, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1213, in __request verbose=self.__verbose >= 3, File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 677, in single_request self.get_auth_info() File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 629, in get_auth_info self._handle_exception(e, service=service) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 578, in _handle_exception raise errors.TicketExpired()
ipa.ipaclient.install.ipa_certupdate.CertUpdate: DEBUG: The ipa-certupdate command failed, exception: TicketExpired: Ticket expired ipa.ipaclient.install.ipa_certupdate.CertUpdate: ERROR: Ticket expired ipa.ipaclient.install.ipa_certupdate.CertUpdate: ERROR: The ipa-certupdate command failed.
Restarting ipa did not help. ???
ipa-certupdate needs to be run with a kerberos ticket. Did you run kinit admin before launching the command, and is your ticket still valid (klist will provide the expiration date)?
Flo.
Regards Harri
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi Flo,
On 12/12/17 2:50 PM, Florence Blanc-Renaud via FreeIPA-users wrote:
On 12/10/2017 10:58 AM, Harald Dunkel via FreeIPA-users wrote:
Hi Flo,
On 12/08/17 15:36, Florence Blanc-Renaud via FreeIPA-users wrote:
Hi,
I would try to remove the new root CA from LDAP and re-import it using ipa-cacert-manage install -t C,, This should create the entry with the appropriate attributes.
Flo
Result: The new root CA certificate shows much better attributes in ldap:
dn: cn=CN\3Droot-CA\2COU\3Dexample Certificate Authority\2CO\3Dexample AG\2CC\3DDE,cn=certificates,cn=ipa,cn=etc,dc=example,dc=de ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1 cn: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE objectClass: ipaCertificate objectClass: pkiCA objectClass: ipaKeyPolicy objectClass: top ipaCertSubject: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE ipaPublicKey:: MIICIjAN... cACertificate;binary:: MIIGDTCC... ipaKeyTrust: trusted ipaCertIssuerSerial: CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE;1
A lot of ipaKeyExtUsage attributes appear to be missing, though, compared to the old root CA certificate. Is this expected?
The ipaKeyExtUsage attribute is built from the trust flags provided to ipa-cacert-manage install, so it looks normal for me.
My concern is, it looks much more restricted than the old root CA cerificate:
# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,,
Shouldn't it be "CT,C,C" as well?
ipa-certupdate needs to be run with a kerberos ticket. Did you run kinit admin before launching the command, and is your ticket still valid (klist will provide the expiration date)?
Nope, that was the problem. I was just looking for the certificate, ignoring Kerberos.
ipa-cert-update said
# ipa-certupdate trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'schema' to json server 'https://ipa1.example.de/ipa/json' trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'ca_is_enabled' to json server 'https://ipa1.example.de/ipa/json' [try 1]: Forwarding 'ca_find/1' to json server 'https://ipa1.example.de/ipa/json' Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful
dmesg shows that there was a core dump:
[108604.869633] ns-slapd[23051]: segfault at 10 ip 00007fb60841dc30 sp 00007fb60af56c88 error 4 in libpthread-2.17.so[7fb608414000+17000]
Problem: The certificate in /etc/ipa/ca.crt and /usr/share/ipa/html/\ ca.crt is still old. The files have been touched, but not replaced by the new certificate.
Regards Harri
Hi Flo,
On 12/12/17 3:59 PM, Harald Dunkel via FreeIPA-users wrote:
My concern is, it looks much more restricted than the old root CA cerificate:
# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,,
Shouldn't it be "CT,C,C" as well?
: :
ipa-cert-update said
# ipa-certupdate trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'schema' to json server 'https://ipa1.example.de/ipa/json' trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'ca_is_enabled' to json server 'https://ipa1.example.de/ipa/json' [try 1]: Forwarding 'ca_find/1' to json server 'https://ipa1.example.de/ipa/json' Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful
dmesg shows that there was a core dump:
[108604.869633] ns-slapd[23051]: segfault at 10 ip 00007fb60841dc30 sp 00007fb60af56c88 error 4 in libpthread-2.17.so[7fb608414000+17000]
Problem: The certificate in /etc/ipa/ca.crt and /usr/share/ipa/html/\ ca.crt is still old. The files have been touched, but not replaced by the new certificate.
AFAICT this is not as documented. Would you suggest to file a bug report?
Regards Harri
On 12/13/2017 04:39 PM, Harald Dunkel via FreeIPA-users wrote:
Hi Flo,
On 12/12/17 3:59 PM, Harald Dunkel via FreeIPA-users wrote:
My concern is, it looks much more restricted than the old root CA cerificate:
# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE C,,
Shouldn't it be "CT,C,C" as well?
: :
Hi,
the flags here will be the same as the ones used with the command ipa-cacert-manage install -t <flags>. If I recall correctly, in most cases you need only C,, but if your deployment requires more flags (for instance the external CA is used to sign Smart Card certificates), you can tune this by providing the required flags in ipa-cacert-manage install.
ipa-cert-update said
# ipa-certupdate trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'schema' to json server 'https://ipa1.example.de/ipa/json' trying https://ipa1.example.de/ipa/json [try 1]: Forwarding 'ca_is_enabled' to json server 'https://ipa1.example.de/ipa/json' [try 1]: Forwarding 'ca_find/1' to json server 'https://ipa1.example.de/ipa/json' Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful
dmesg shows that there was a core dump:
[108604.869633] ns-slapd[23051]: segfault at 10 ip 00007fb60841dc30 sp 00007fb60af56c88 error 4 in libpthread-2.17.so[7fb608414000+17000]
Problem: The certificate in /etc/ipa/ca.crt and /usr/share/ipa/html/\ ca.crt is still old. The files have been touched, but not replaced by the new certificate.
AFAICT this is not as documented. Would you suggest to file a bug report?
The files should contain multiple certificates (IPA CA and the external CA certificates). If it is not the case, please check first if there were AVC issues (if running in SElinux enforcing mode), and feel free to file a bug.
Flo
Regards Harri _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi Flo, Rob,
On 12/14/17 9:27 AM, Florence Blanc-Renaud via FreeIPA-users wrote:
The files should contain multiple certificates (IPA CA and the external CA certificates). If it is not the case, please check first if there were AVC issues (if running in SElinux enforcing mode), and feel free to file a bug.
You are right, its a set of certificates.
One last question: Is it safe to drop the old root CA from the certutil database? Its no longer in LDAP, anyway. "getcert list" doesn't mention any certificates derived from the old PKI, either.
I highly appreciate your support and patience
Regards Harri
On 12/14/2017 05:09 PM, Harald Dunkel via FreeIPA-users wrote:
Hi Flo, Rob,
On 12/14/17 9:27 AM, Florence Blanc-Renaud via FreeIPA-users wrote:
The files should contain multiple certificates (IPA CA and the external CA certificates). If it is not the case, please check first if there were AVC issues (if running in SElinux enforcing mode), and feel free to file a bug.
You are right, its a set of certificates.
One last question: Is it safe to drop the old root CA from the certutil database? Its no longer in LDAP, anyway. "getcert list" doesn't mention any certificates derived from the old PKI, either.
I highly appreciate your support and patience
Regards Harri _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi,
"getcert list" only shows the certificates tracked by certmonger. Before dropping the old root CA, I would check with certutil if the NSS db contains valid certificates signed by the old root CA. If it is not the case, you are safe to remove it (anyway, it would be easy to re-add it, just keep a saved copy with certutil -L -d $nssdb -n $oldrootCA -a -o oldrootca.crt)
Flo
On 12/14/17 17:09, Harald Dunkel via FreeIPA-users wrote:
Hi Flo, Rob,
On 12/14/17 9:27 AM, Florence Blanc-Renaud via FreeIPA-users wrote:
The files should contain multiple certificates (IPA CA and the external CA certificates). If it is not the case, please check first if there were AVC issues (if running in SElinux enforcing mode), and feel free to file a bug.
You are right, its a set of certificates.
Maybe a related problem: ldapmodify gives me
% ldapmodify -ZZ -D "cn=directory manager" -W -a ldap_start_tls: Operations error (1) additional info: SSL connection already established.
???
Regards Harri
On 01/10/2018 10:06 AM, Harald Dunkel via FreeIPA-users wrote:
On 12/14/17 17:09, Harald Dunkel via FreeIPA-users wrote:
Hi Flo, Rob,
On 12/14/17 9:27 AM, Florence Blanc-Renaud via FreeIPA-users wrote:
The files should contain multiple certificates (IPA CA and the external CA certificates). If it is not the case, please check first if there were AVC issues (if running in SElinux enforcing mode), and feel free to file a bug.
You are right, its a set of certificates.
Maybe a related problem: ldapmodify gives me
% ldapmodify -ZZ -D "cn=directory manager" -W -a ldap_start_tls: Operations error (1) additional info: SSL connection already established.
Hi,
with -ZZ ldapsearch will be using startTLS and the error means that it's trying to establish a startTLS session over an ssl connection. This probably happens because the /etc/openldap/ldap.conf (or ldaprc, .ldaprc) defines URI ldaps://hostname
Can you try with ldap instead of ldaps: ldapmodify -ZZ -D "cn=directory manager" -W -H ldap://`hostname`
HTH, Flo
???
Regards Harri _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
freeipa-users@lists.fedorahosted.org
-
Andrew Radygin -
Florence Blanc-Renaud -
Harald Dunkel -
Harald Dunkel -
Rob Crittenden