Bug 1626988
| Summary: | LDAPS can't connect to AD - connection reset by peer | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Vladislav Walek <vwalek> |
| Component: | apiserver-auth | Assignee: | Mo <mkhan> |
| Status: | CLOSED ERRATA | QA Contact: | Chuan Yu <chuyu> |
| Severity: | high | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 3.7.0 | CC: | aos-bugs, chuyu, erich, evb, jokerman, maszulik, mfojtik, mkhan, mmccomas, pdwyer, scheng, scuppett, ssorce, tparsons, vwalek, xtian, xxia |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | 3.11.z | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-01-10 09:03:58 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: | |||
|
Description
Vladislav Walek
2018-09-10 08:59:44 UTC
Sounds like there are incompatibility issues between Microsoft AD servers using TLS1.2 with certs using SHA512 as their hash. Here there is a discussion that hints in that direction: https://social.technet.microsoft.com/Forums/en-US/b6ffa278-4a04-4609-ac35-8390f5ba9cb6/ldap-over-ssl-on-windows-2012r2-server-dcs-tls-12-not-working?forum=winserversecurity Two possible workarounds suggested are: - disable TLS1.2 in the Widnows DC - change certificates to use supported hashes I do not have reason to believe anything is amiss on the openshift side, sounds like a bug or an unfortunate set of defaults in Windows server certificate creation. I have reply from customer: The 2 options are "workarounds" on AD side. The actual reason seems that the client does not support SHA512 sigantures. How can openshift be changed to support SHA512? No the TLS1.2 protocol standard does not support SHA512 signatures, we are not going to deviate from protocol standards, as those are implemented directly by Go crypto libraries and not Openshift itself. Sorry but this is not we can solve on the Openshift side. I do not know if SSSD/Apache/etc support their AD configuration, but if they do, they could switch to the remote basic auth IDP [1] and have Apache handle the TLS to AD. [1] https://docs.okd.io/latest/install_config/sssd_for_ldap_failover.html (In reply to Mo from comment #5) > I do not know if SSSD/Apache/etc support their AD configuration, but if they > do, they could switch to the remote basic auth IDP [1] and have Apache > handle the TLS to AD. > > [1] https://docs.okd.io/latest/install_config/sssd_for_ldap_failover.html True, an SSSD joined to AD doesn't even care for LDAPS,a s it uses plain LDAP + GSSAPI for encryption, so it would work w/o certs... and avoid the whole issue. SHA512 is supported for signing and verifying certificates, but if you read appendinx A.6 and C you will see there are no ciphers with SHA512 in them. It's ether SHA or SHA256. Microsoft made a Mistake and forced Windows server to use RSA/SHA512 and ECDSA/SHA512 in TLS1.2, when their certificates use SHA512 for signing. Sorry for the above I had misunderstood the issue. After re-reading the case I figured out that you are almost certainly affected by a missing signatureAlgorithm support issue in golang crypto. This is the Issue: https://github.com/golang/go/issues/22422 And this is the commit that fixes the issue: https://github.com/golang/go/commit/96cd66b266a24d8ed1f66dfa10ddb86d88b50fca It is tagged to lang in golang 1.11 so we can properly fix this issue only once we pick up go lang 1.11 ourselves in a future version or get this fix backported. Till then the workarounds are the best way to go. I am goign to move this to the master team as they are the ones currently dealing with rebases and decisions about pulling in new go lang versions. So just one more bit of context, the reason this fails with Microsoft and not other servers is that Microsoft implemented TLS1.2 in a stricter way than others. But their implementation is technically correct. I believe the fix was included in go1.10: https://github.com/golang/go/blob/go1.10/src/crypto/tls/common.go#L145-L146 https://github.com/golang/go/blob/go1.10/src/crypto/tls/prf.go#L189-L190 so it should be fixed by upgrading to v3.11 Per gdb, 3.11 uses go1.10.2 $ ls atomic-openshift-3.11.16-1.git.0.b48b8f8.el7.x86_64.rpm openshift $ gdb openshift GNU gdb (GDB) Fedora 8.1.1-3.fc28 ... (gdb) p 'runtime.buildVersion' $1 = 0x5197fe3 "go1.10.2" I wonder if this is not a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1643119 The issue fixed in v3.11.43 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-2019:0024 |