Bug 668899 - some server certificates refused with inadequate type error
Summary: some server certificates refused with inadequate type error
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap
Version: 14
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Jan Vcelak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 669846
TreeView+ depends on / blocked
 
Reported: 2011-01-12 00:07 UTC by Yi Zhang
Modified: 2013-03-04 01:28 UTC (History)
7 users (show)

(edit)
Clone Of:
: 669846 (view as bug list)
(edit)
Last Closed: 2011-09-25 03:47:19 UTC


Attachments (Terms of Use)
ldapmodify run with -d 255 (14.48 KB, text/plain)
2011-01-12 10:28 UTC, Jakub Hrozek
no flags Details
openssl x509 -text -in /etc/ipa/ca.crt (2.66 KB, text/plain)
2011-01-12 10:57 UTC, Jakub Hrozek
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.