Bug 668899

Summary: some server certificates refused with inadequate type error
Product: [Fedora] Fedora Reporter: Yi Zhang <yzhang>
Component: openldapAssignee: Jan Vcelak <jvcelak>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 14CC: dpal, jgalipea, jhrozek, jvcelak, jzeleny, rmeggins, tsmetana
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openldap-2.4.23-10.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 669846 (view as bug list) Environment:
Last Closed: 2011-09-25 03:47:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 669846    
Attachments:
Description Flags
ldapmodify run with -d 255
none
openssl x509 -text -in /etc/ipa/ca.crt none

Description Yi Zhang 2011-01-12 00:07:45 UTC 
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:
Comment 1 Rich Megginson 2011-01-12 01:32:50 UTC 
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?
Comment 3 Jan Zeleny 2011-01-12 08:59:31 UTC 
I just tried latest git snapshot with openldap-2.4.23-5.fc14.x86_64 and everything works ok. Please retest and confirm.
Comment 4 Jakub Hrozek 2011-01-12 10:28:35 UTC 
Created attachment 472988 [details]
ldapmodify run with -d 255
Comment 5 Jakub Hrozek 2011-01-12 10:30:28 UTC 
(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
---
Comment 6 Jan Zeleny 2011-01-12 10:44:23 UTC 
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".
Comment 7 Jakub Hrozek 2011-01-12 10:48:31 UTC 
(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.
Comment 8 Jakub Hrozek 2011-01-12 10:57:27 UTC 
Created attachment 472998 [details]
openssl x509 -text -in /etc/ipa/ca.crt
Comment 9 Rich Megginson 2011-01-12 16:23:37 UTC 
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?
Comment 10 Rob Crittenden 2011-01-12 17:04:35 UTC 
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.
Comment 11 Jakub Hrozek 2011-01-12 17:13:34 UTC 
(In reply to comment #10)
> I'm not sure which one Yi is using.

I hit the bug with self-signed.
Comment 12 Jan Vcelak 2011-01-12 17:46:52 UTC 
tlsm_auth_cert_handler, tls_m.c:1028

SECCertUsage certUsage = isServer ? certUsageSSLClient : certUsageSSLServer;

Should be:

SECCertUsage certUsage = isServer ? certUsageSSLServer : certUsageSSLClient;

Rich, am I right?
Comment 13 Rich Megginson 2011-01-12 17:56:51 UTC 
(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.
Comment 14 Rich Megginson 2011-01-12 17:58:00 UTC 
(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.
Comment 15 Rob Crittenden 2011-01-12 18:08:53 UTC 
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"
Comment 16 Rich Megginson 2011-01-12 21:00:22 UTC 
Does the cacert pass certutil -V?
Comment 17 Jan Vcelak 2011-01-12 21:17:10 UTC 
(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
Comment 18 Rich Megginson 2011-01-12 21:29:05 UTC 
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
Comment 19 Rich Megginson 2011-01-13 21:28:58 UTC 
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
?
Comment 20 Jan Vcelak 2011-01-13 23:56:58 UTC 
[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
Comment 21 Rich Megginson 2011-01-15 00:23:31 UTC 
ITS opened and patch submitted upstream: http://www.openldap.org/its/index.cgi?findid=6791
Comment 22 Jan Vcelak 2011-01-20 17:25:37 UTC 
Fixed in openldap-2.4.23-6.fc14
Comment 23 Fedora Update System 2011-01-20 17:27:14 UTC 
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
Comment 24 Fedora Update System 2011-01-21 23:02:05 UTC 
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
Comment 25 Fedora Update System 2011-01-25 13:35:18 UTC 
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
Comment 26 Fedora Update System 2011-02-02 12:43:26 UTC 
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
Comment 27 Fedora Update System 2011-03-01 12:42:09 UTC 
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).
Comment 28 Fedora Update System 2011-03-01 12:42:54 UTC 
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).
Comment 29 Fedora Update System 2011-03-19 00:21:02 UTC 
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
Comment 30 Fedora Update System 2011-09-25 03:46:38 UTC 
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.