Description of problem: I installed ipa daily build (1/11/2011) today and it failed. The error msg says: Unable to set admin password Command '/usr/bin/ldappasswd -h dhcp-137.sjc.redhat.com -ZZ -x -D cn=Directory Manager -y /var/lib/ipa/tmpjUBeXx -T /var/lib/ipa/tmpazJ5aT uid=admin,cn=users,cn=accounts,dc=sjc,dc=redhat,dc=com' returned non-zero exit status 1 Based on Devs (Rob and Simo)'s advise, I downgrade openldap from openldap-2.4.23-5.fc14.i686 openldap-clients-2.4.23-5.fc14.i686 openldap-devel-2.4.23-5.fc14.i686 To: [root@dhcp-137 ~]# rpm -qa | grep openldap openldap-clients-2.4.23-4.fc14.i686 openldap-devel-2.4.23-4.fc14.i686 openldap-2.4.23-4.fc14.i686 And everything works fine. The installation is error free. Devs might want to dig into this to address the real issue between IPA and openldap libs. Version-Release number of selected component (if applicable):ipa-server-2.0-0.2011011115gitc778919.fc14.i686 How reproducible: always Steps to Reproduce: 1. yum install ipa-server 2. ipa-server-install (select defaults) Actual results: install fails at last step, error msg: Unable to set admin password Command '/usr/bin/ldappasswd -h dhcp-137.sjc.redhat.com -ZZ -x -D cn=Directory Manager -y /var/lib/ipa/tmpjUBeXx -T /var/lib/ipa/tmpazJ5aT uid=admin,cn=users,cn=accounts,dc=sjc,dc=redhat,dc=com' returned non-zero exit status 1 Expected results: Additional info:
What is the TLS configuration? Where is the TLS_CACERT or CACERTDIR specified? Are there other TLS configuration variables? Can this be reproduced just using the ldappasswd command line tool or is the only way to reproduce this actually going through an ipa install?
I just tried latest git snapshot with openldap-2.4.23-5.fc14.x86_64 and everything works ok. Please retest and confirm.
Created attachment 472988 [details] ldapmodify run with -d 255
(In reply to comment #3) > I just tried latest git snapshot with openldap-2.4.23-5.fc14.x86_64 and > everything works ok. Please retest and confirm. I managed to reproduce the issue with IPA server that was both build against openldap-devel libraries with release -5 as well as installed on machine with the same runtime release. Attached is a full debug log (I just added -d 255 to the ldapmodify invocation). The most interesting part is probably at the very end: --- TLS: certificate [CN=vm-061.idm.lab.bos.redhat.com,O=IDM.LAB.BOS.REDHAT.COM] is not valid - error -8102:Unknown code ___f 90. tls_write: want=7, written=7 0000: 15 03 01 00 02 02 2e ....... TLS: error: connect - force handshake failure: errno 0 - moznss error -8102 TLS: can't connect: TLS error -8102:Unknown code ___f 90. ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS error -8102:Unknown code ___f 90 ---
Ok, now I've hit the issue as well, the key point seems to be building - if built with release -5, the failure occurs. Based on that I guess the issue is in one of our DS plugins. According to http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html the error means "Certificate key usage inadequate for attempted operation".
(In reply to comment #1) > What is the TLS configuration? Where is the TLS_CACERT or CACERTDIR specified? env = { 'LDAPTLS_CACERTDIR':os.path.dirname(CACERT), 'LDAPTLS_CACERT':CACERT } Where CACERT is /etc/ipa/ca.crt. This cert is created during the IPA installation. > Are there other TLS configuration variables? No. The only TLS configuration is with the env dictionary as seen above. > Can this be reproduced just > using the ldappasswd command line tool or is the only way to reproduce this > actually going through an ipa install? I managed to reproduce this with ldappasswd when I pointed it at the right cert by setting LDAPTLS_CACERT{,DIR} to the ones IPA installation uses. I don't have a fully self-contained testcase.
Created attachment 472998 [details] openssl x509 -text -in /etc/ipa/ca.crt
I made certificate checking more flexible in -5 to catch different types of cert errors and usages that openssl allows (i.e. make openldap with moznss work like openldap with openssl). 1) Where is /etc/ipa/ca.crt generated? 2) Is X509v3 Key Usage: critical Digital Signature, Non Repudiation, Certificate Sign valid for a CA cert?
A dogtag-generated CA looks like: Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 9a:37:cb:95:97:a1:4e:bc:84:fe:f4:84:6a:76:f6:f9: 21:da:32:24 Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: "http://slinky.example.com:9180/ca/ocsp" Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate An IPA self-signed CA looks like: Signed Extensions: Name: Certificate Type Data: <SSL CA,S/MIME CA,ObjectSigning CA> Name: Certificate Basic Constraints Critical: True Data: Is a CA with no maximum path length. Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Certificate Signing I'm not sure which one Yi is using.
(In reply to comment #10) > I'm not sure which one Yi is using. I hit the bug with self-signed.
tlsm_auth_cert_handler, tls_m.c:1028 SECCertUsage certUsage = isServer ? certUsageSSLClient : certUsageSSLServer; Should be: SECCertUsage certUsage = isServer ? certUsageSSLServer : certUsageSSLClient; Rich, am I right?
(In reply to comment #12) > tlsm_auth_cert_handler, tls_m.c:1028 > > SECCertUsage certUsage = isServer ? certUsageSSLClient : certUsageSSLServer; > > Should be: > > SECCertUsage certUsage = isServer ? certUsageSSLServer : certUsageSSLClient; > > Rich, am I right? No. tls_m.c:1028 is tlsm_auth_cert_handler() which is called to verify the _peer_ certificate. isServer is true if the code is running as a server, and false if the server is running as a client. So if isServer is True, then the _peer_ cert must be a client, so we must verify it as a client cert, and vice versa. The same sort of logic is used in various places in the NSS code.
(In reply to comment #10) > A dogtag-generated CA looks like: > > Signed Extensions: > Name: Certificate Authority Key Identifier > Key ID: > 9a:37:cb:95:97:a1:4e:bc:84:fe:f4:84:6a:76:f6:f9: > 21:da:32:24 > > Name: Authority Information Access > Method: PKIX Online Certificate Status Protocol > Location: > URI: "http://slinky.example.com:9180/ca/ocsp" > > Name: Certificate Key Usage > Critical: True > Usages: Digital Signature > Non-Repudiation > Key Encipherment > Data Encipherment > > Name: Extended Key Usage > TLS Web Server Authentication Certificate > TLS Web Client Authentication Certificate There is no Certificate Basic Constraints extension in the DogTag generated CA cert? According to awnuk there should be, otherwise it is not a valid CA certificate. > > An IPA self-signed CA looks like: > > Signed Extensions: > Name: Certificate Type > Data: <SSL CA,S/MIME CA,ObjectSigning CA> > > Name: Certificate Basic Constraints > Critical: True > Data: Is a CA with no maximum path length. > > Name: Certificate Key Usage > Critical: True > Usages: Digital Signature > Non-Repudiation > Certificate Signing > > I'm not sure which one Yi is using.
My mistake, I pasted in the wrong cert: Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 9a:37:cb:95:97:a1:4e:bc:84:fe:f4:84:6a:76:f6:f9: 21:da:32:24 Name: Certificate Basic Constraints Critical: True Data: Is a CA with no maximum path length. Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Certificate Signing CRL Signing Name: Certificate Subject Key ID Data: 9a:37:cb:95:97:a1:4e:bc:84:fe:f4:84:6a:76:f6:f9: 21:da:32:24 Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: "http://slinky.example.com:9180/ca/ocsp"
Does the cacert pass certutil -V?
(In reply to comment #16) > Does the cacert pass certutil -V? I don't know how to verify CA certificate, but LDAP server certificate is fine: # /usr/bin/certutil -d /etc/dirsrv/slapd-LOCALDOMAIN/ -n Server-Cert -V -u V certutil: certificate is valid
I just want to know 1) Why NSS complains about the cert 2) Does the openldap cert verification code need to change, or is there really something wrong with the CA cert
The error is complaining about CN=vm-061.idm.lab.bos.redhat.com,O=IDM.LAB.BOS.REDHAT.COM which is the server cert? Can someone post the output of certutil -d /etc/dirsrv/slapd-INSTANCENAME -L -n "name of server cert" or if the cert is in pem format openssl x509 -in /path/name/of/cert.pem -text ?
[root@f14 ~]# certutil -d /etc/dirsrv/slapd-LOCALDOMAIN/ -L -n "Server-Cert" Certificate: Data: Version: 3 (0x2) Serial Number: 1001 (0x3e9) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "CN=LOCALDOMAIN Certificate Authority" Validity: Not Before: Wed Jan 12 14:23:21 2011 Not After : Tue Jan 12 14:23:21 2021 Subject: "CN=f14.localdomain,O=LOCALDOMAIN" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: ca:4f:bd:f3:a9:23:74:dc:5b:71:54:ba:d7:fd:8f:2d: f8:16:03:c2:13:cf:87:09:01:03:83:76:50:43:98:3d: 54:49:08:e7:3a:29:9b:8b:47:86:4a:fa:60:90:54:6f: 91:3d:0a:10:30:6d:f2:20:96:c1:77:15:b0:fe:46:02: 13:ce:71:ac:a8:51:d7:94:a3:48:d0:9f:ea:1a:9c:c0: 2d:76:90:48:a1:61:fd:56:17:cd:11:39:d6:c3:84:e0: 3d:c7:33:a7:7e:f3:f3:b2:30:cf:b6:cc:5e:1a:ca:b8: dd:18:8b:1c:f4:fb:46:aa:66:b6:1a:93:69:1b:50:d0: bf:2f:3f:d7:6c:ac:c9:bb:6c:b5:27:0b:dc:d8:53:39: 73:83:a8:c0:15:e4:bc:1c:56:76:76:8b:fd:e4:5a:b9: a5:3b:35:c6:00:6b:87:c1:25:47:5b:98:71:43:d3:21: 2f:d2:01:bc:5f:0b:46:b2:b0:93:c4:ce:ba:e2:ce:22: b7:a0:3a:89:7f:3a:16:89:df:ba:a5:e8:1e:1b:e8:20: 86:3a:2b:c6:7f:57:bc:91:ab:38:30:9b:c8:73:fe:d9: 35:f6:7d:2a:f4:1c:58:79:c9:cb:22:e1:9b:37:53:9e: e8:74:14:b3:62:fa:2b:e7:dc:73:a8:60:3a:73:83:f7 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Type Data: <SSL Server> Name: Certificate Key Usage Usages: Key Encipherment Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature: 05:55:4d:3c:07:7b:62:de:71:5e:06:f1:03:74:04:98: f6:7f:6f:80:21:08:30:53:a8:10:04:04:2d:dc:54:84: f8:6b:ab:86:45:62:a7:73:5a:27:ae:cc:f0:2b:a2:9a: 6b:71:35:34:8c:4a:71:85:c5:af:80:b6:44:e0:35:2b: 56:9e:00:bc:e9:d7:7e:5d:d0:da:3a:ea:71:2b:dc:61: 79:44:2f:27:8d:6c:04:c2:37:85:93:a5:78:e9:ed:16: c2:23:90:36:63:e5:c7:1c:3e:b8:7b:bd:d7:85:d0:cd: 2e:47:1a:0a:c4:bb:fd:57:a8:65:22:03:5c:a1:f8:46 Fingerprint (MD5): 62:B8:31:A3:9A:72:94:1C:E7:63:E1:48:10:BB:07:15 Fingerprint (SHA1): 3D:15:33:3C:C1:94:25:A5:8D:A8:1F:7D:DF:E2:1F:27:4D:18:6F:65 Certificate Trust Flags: SSL Flags: User Email Flags: User Object Signing Flags: User
ITS opened and patch submitted upstream: http://www.openldap.org/its/index.cgi?findid=6791
Fixed in openldap-2.4.23-6.fc14
openldap-2.4.23-6.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/openldap-2.4.23-6.fc14
openldap-2.4.23-6.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openldap'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/openldap-2.4.23-6.fc14
openldap-2.4.23-7.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/openldap-2.4.23-7.fc14
openldap-2.4.23-8.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/openldap-2.4.23-8.fc14
Package openldap-2.4.21-12.fc13: * should fix your issue, * was pushed to the Fedora 13 updates-testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openldap-2.4.21-12.fc13' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/openldap-2.4.21-12.fc13 then log in and leave karma (feedback).
Package openldap-2.4.23-9.fc14: * should fix your issue, * was pushed to the Fedora 14 updates-testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openldap-2.4.23-9.fc14' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/openldap-2.4.23-9.fc14 then log in and leave karma (feedback).
openldap-2.4.23-10.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/openldap-2.4.23-10.fc14
openldap-2.4.23-10.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.