Hello,

I am assuming the regression in your case really comes from a change in OpenLDAP. The only change that was introduced in the respective update was a fix for bug 1740070. That means it is more strict when it comes to hostname checking wrt. CN and SAN -- now, unlike before, if checking against certificate-provided SANs fails (i.e. no match) the subsequent checking against CN is not done any more and the entire checking is considered to have failed. Therefore, in your case I would check the certificates you use to see if they satisfy this new condition.

HTH,
Matus

Hello Matus,

thank you very much for the explanation and your quick response. 

We are using the default selfsigned SSL-Certificate which will be generated when you install FreeIPA/Red Hat IDM.

Ive checked the certificates and couldn't find any SAN-entries, the provided CN matches the FQDN of the host.

openssl s_client does not show any error messages when connecting with starttls, the response shows Verification: OK

Is the SAN-Entry in the Certificate mandatory now? 


Best regards,
Dominic

Dominic, does your LDAP server cert contain a Subject Alt Name (SAN) extension of type otherName or any other type?

Hi Christian,

unfortunately the default self-signed certificate does not contain any SAN extensions :-( 

Best regards,
Dominic

(In reply to Dominic Kohls from comment #5)
> Hi Christian,
> 
> unfortunately the default self-signed certificate does not contain any SAN
> extensions :-( 

Could you please show us the output of "sudo certutil -d /etc/dirsrv/slapd-IPA-EXAMPLE/ -L -n Server-Cert"? Replace "IPA-EXAMPLE" with your REALM.

Patch is attached to parent bug #1788572

Hi Christian,

please find the requested certificate below.


[root@FQDN ~]# certutil -d /etc/dirsrv/slapd-EXAMPLE.COM/ -L -n Server-Cert
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 21 (0x15)
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=Certificate Authority,O=EXAMPLE.COM"
        Validity:
            Not Before: Fri Apr 27 17:19:20 2018
            Not After : Mon Apr 27 17:19:20 2020
        Subject: "CN=FQDN.EXAMPLE.COM,O=EXAMPLE.COM"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    b6:5b:67:98:f0:d1:61:ef:30:da:0d:07:01:d6:13:5d:
                    fb:08:05:df:6c:75:40:d9:47:5d:2c:95:18:a7:b6:77:
                    33:2a:1a:a7:18:c3:c6:0f:2b:5a:90:b9:b5:8e:fe:19:
                    f1:58:3c:6f:ad:48:f5:bb:22:cb:b7:6d:18:6d:f7:5b:
                    4f:ca:95:c5:f8:d0:4e:4b:2d:2c:02:01:7f:cb:f4:f2:
                    dd:13:3d:d2:8e:21:dc:57:4b:05:7d:29:89:d5:55:03:
                    51:b5:eb:30:65:43:ad:1a:48:5d:cb:e3:b0:a6:03:6e:
                    22:fb:e2:48:8c:0a:d2:29:82:72:59:3e:9a:52:f8:27:
                    6a:df:90:20:5d:cc:8e:57:aa:71:ba:b1:14:03:36:39:
                    46:88:e9:97:36:8e:eb:33:13:c9:f6:11:59:cc:37:1d:
                    de:7c:a2:6b:d9:f5:ed:cb:d7:c0:4c:e6:28:7a:37:42:
                    27:d4:04:b6:f2:0b:f4:ab:d4:77:e3:00:e4:10:84:33:
                    24:5a:52:68:92:28:97:a8:31:57:c5:f7:d6:94:f3:7d:
                    fd:8f:b8:16:23:ea:52:e2:37:7d:2b:b9:0d:c2:b5:fc:
                    10:49:aa:45:f2:41:ec:db:68:d6:02:6f:4a:0e:23:02:
                    f3:9a:82:11:06:5a:26:8c:25:d7:e6:13:b8:f2:8b:69
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name: Certificate Authority Key Identifier
            Key ID:
                1b:2f:6d:48:1c:53:7e:60:46:a3:34:aa:a3:1d:8a:9a:
                41:21:d0:46

            Name: Authority Information Access
            Method: PKIX Online Certificate Status Protocol
            Location:
                URI: "http://ipa-ca.EXAMPLE.COM/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

            Name: CRL Distribution Points
            Distribution point:
                URI: "http://ipa-ca.EXAMPLE.COM/ipa/crl/MasterCRL
                    .bin"
                CRL issuer:
                    Directory Name: "CN=Certificate Authority,O=ipaca"

            Name: Certificate Subject Key ID
            Data:
                66:47:8b:9f:35:06:f8:a3:05:be:05:5b:59:42:33:ce:
                e6:f6:44:ae

            Name: Certificate Subject Alt Name
            Other Name: "ldap/FQDN.EXAMPLE.COM"
                OID: Microsoft NT Principal Name
            Other Name: Sequence {
                [0]: {
                    1b:17:43:4f:4d:50:55:54:41:43:45:4e:54:45:52:2d:
                    4d:44:53:2e:4c:4f:43:41:4c
                }
                [1]: {
                    Sequence {
                        [0]: {
                            1 (0x1)
                        }
                        [1]: {
                            Sequence {
                                1b:04:6c:64:61:70
                                1b:27:63:63:64:65:66:66:6d:69:73:70:30:31:6c:
                                64:70:2e:63:6f:6d:70:75:74:61:63:65:6e:74:65:
                                72:2d:6d:64:73:2e:6c:6f:63:61:6c
                            }
                        }
                    }
                }
            }
                OID: OID.1.3.6.1.5.2.2

    Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
    Signature:
        7e:51:29:92:82:40:3d:86:de:16:47:08:d0:ac:14:da:
        92:05:48:7a:5e:06:43:23:82:14:7e:55:d9:f7:1a:5b:
        dc:c9:71:d5:a9:07:3b:1f:eb:5b:0c:ff:3f:96:ee:bb:
        16:9f:06:f4:7b:3f:3b:af:0d:6e:ed:48:a5:99:dc:8f:
        10:51:72:1c:03:64:30:04:8e:53:71:8d:80:ca:7f:cb:
        54:19:65:d5:63:9e:25:e3:29:d7:59:2f:33:e8:ee:0a:
        b2:c2:38:a6:c4:63:2a:56:98:bf:ab:99:86:fa:11:51:
        9a:ff:77:f3:37:6d:f0:66:8a:69:f1:4b:1f:b1:64:3b:
        39:bb:be:5e:5f:d1:f0:42:ec:3e:f7:c1:16:c9:13:cd:
        0b:dd:c9:c8:d1:8f:ed:ab:1d:21:68:f5:34:43:0f:5e:
        ef:82:b8:9a:23:b2:6c:bf:86:a4:82:06:63:38:a9:03:
        90:81:2d:d4:8e:7a:af:3e:8c:f7:b4:e3:b4:c3:dd:51:
        4d:eb:57:7b:87:27:9b:e7:3c:c9:12:cf:93:c4:4e:68:
        75:42:a9:4a:56:d5:04:08:75:e7:9e:24:6d:e0:91:a5:
        3d:a8:fa:1e:fd:ec:b7:fb:2a:2f:27:1b:43:d6:9c:28:
        0c:4f:2a:4b:a3:5e:aa:57:fd:e5:61:e7:a8:76:4c:02
    Fingerprint (SHA-256):
        13:F8:7C:4B:77:E0:5E:5B:3E:BD:CC:E6:07:76:30:15:00:43:BF:6E:BE:DF:BF:2B:75:90:9E:76:E9:42:8F:E8
    Fingerprint (SHA1):
        2B:79:6C:F2:E7:CA:A2:1E:75:05:84:6D:89:0F:93:A7:84:04:CE:B9

    Mozilla-CA-Policy: false (attribute missing)
    Certificate Trust Flags:
        SSL Flags:
            User
        Email Flags:
            User
        Object Signing Flags:
            User

Thanks Dominic!

your certificate has two SAN entries of type "other name" and no entry of type "DNS name". That's exactly the same issue as in the other cases. This scenario will be fixed by our patch.

Matus and I were worried that your case might be different than the other cases. We wanted to be sure that we address your problem as well.

Hi Christian,

thank you for the explanation! 

In comment 5 I checked the certificate with openssl s_client and just saw the following entries which made me think there are no SAN entries set.

            X509v3 Subject Alternative Name:
                othername:<unsupported>, othername:<unsupported>


Many thanks for all your work!

The SAN extension can handle more than just DNS names and IP addresses. The "other name" type is a kind of application defined, custom extension. OpenSSL has no code to print SAN general names of type "other name".

Here is the definition from https://tools.ietf.org/html/rfc3280#section-4.2.1.7

   id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }

   SubjectAltName ::= GeneralNames

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

   OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

   EDIPartyName ::= SEQUENCE {
        nameAssigner            [0]     DirectoryString OPTIONAL,
        partyName               [1]     DirectoryString }

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1914