[DOCS-9180] Document required CN / subjectAltName configuration for TLS certificates Created: 20/Oct/16 Updated: 16/Aug/18 Resolved: 12/Aug/18 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Bernie Hackett | Assignee: | Kay Kim (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 5 years, 26 weeks, 3 days ago | ||||||||
| Epic Link: | DOCSP-1769 | ||||||||
| Description |
|
We often get questions from users about TLS handshake failures that are caused by misconfigured TLS certificates. The server and client drivers use the hostname verification algorithm described in RFC2818 Section 3.1, specifically this text:
Users often create TLS certificates that have a SAN dNSName of something like "foo.example.com", and a CN of something like "foobar.example.com". They try to connect to foobar.example.com and the TLS handshake fails, leading to a lot of confusion. TLS is complicated and difficult to explain. Let's try to give the users a fighting chance in this case. |
| Comments |
| Comment by Githook User [ 12/Aug/18 ] |
|
Author: {'username': 'kay-kim', 'email': 'kay.kim@10gen.com', 'name': 'kay'}Message: |
| Comment by Githook User [ 12/Aug/18 ] |
|
Author: {'name': 'kay', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}Message: |
| Comment by Githook User [ 12/Aug/18 ] |
|
Author: {'name': 'kay', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}Message: |
| Comment by Bernie Hackett [ 20/Oct/16 ] |
|
This also matches the behavior of the built in hostname verification in OpenSSL >= 1.0.2 (previous versions didn't support hostname verification). https://www.openssl.org/docs/manmaster/crypto/X509_check_host.html
|