Bug 1788572
Summary: | ipa-client-install will fail with the following error after updating from openldap-2.4.46-9 to openldap-2.4.46-10.el8 | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Dominic Kohls <dominic.kohls> | |
Component: | openldap | Assignee: | Matus Honek <mhonek> | |
Status: | CLOSED ERRATA | QA Contact: | RHDS QE <ds-qe-bugs> | |
Severity: | urgent | Docs Contact: | ||
Priority: | urgent | |||
Version: | 8.1 | CC: | cheimes, dominic.kohls, mhonek, tmihinto, tscherf, vashirov | |
Target Milestone: | rc | Keywords: | ZStream | |
Target Release: | 8.0 | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | openldap-2.4.46-11.el8 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1791065 (view as bug list) | Environment: | ||
Last Closed: | 2020-04-28 17:03:31 UTC | Type: | Bug | |
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: | 1781799, 1791065 |
Description
Dominic Kohls
2020-01-07 14:22:00 UTC
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 |