search

letsencrypt / boulder

An ACME-based certificate authority, written in Go.
Mozilla Public License 2.0
5.22k stars 607 forks source link

Issue without CN #40

Closed jsha closed 8 years ago

jsha commented 9 years ago

The current logic in IssueCertificate only includes the CommonName in subjectAlternateNames if there were no subjectAlternateNames provided in the CSR. Instead, we should always add the CommonName to the subjectAlternateNames if it is not already present there.

jsha commented 9 years ago

From BRs 9.2.2: https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf

Certificate Field:
subject:commonName (OID 2.5.4.3)
Required/Optional:
Deprecated (Discouraged, but not prohibited)
Contents:
If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of
the values contained in the Certificate’s subjectAltName extension (see Section 9.2.1).

So we should probably omit the CN entirely.

jsha commented 9 years ago

Updated issue title to reflect that I think we should issue entirely without CN. Additional supporting docs: RFC 2818 shows that CN has been deprecated since at least May 2000: https://tools.ietf.org/html/rfc2818.

Ryan Hurst's post on the topic: http://unmitigatedrisk.com/?p=381

We should do some browser compatibility testing to determine what (if any) impact this has.

rmhrisk commented 9 years ago

There will be some interoperability with very old devices, that said I think with what I understand your target audience to be this will be a safe change.

jsha commented 9 years ago

Is there documentation anywhere of which devices are affected? Are Android 2.2 / WinXP on the list?

rmhrisk commented 9 years ago

XP will be fine, I think Android 2.1 was the last not to support SANs.

jsha commented 9 years ago

Here's a site with a CN-less cert for testing: https://www.friendsreunited.com/

noloader commented 9 years ago

So we should probably omit the CN entirely....

Yes, very good idea (If I am parsing it correctly). The CN is displayed to the user by various tools (like Microsoft certifcate.msc and Fedora's Certificate Viewer), so the CN should be a friendly name of the entity or organization. The CN should not include a domain name or DNS name.

Here are the rules for domain names and DNS names, if interested. They are an intersection of both PKIX (IETF Internet policies) and CA/B (CA/Browser Forums policies). Browsers don't follow IETF issuing policies, so its important to capture the intersection so the certificate works under as many user agents as possible. (And that's why a tool like wget is more forgiving than browsers).

  1. No domain name or DNS name in the CN (deprecated, not forbidden)
  2. Domain names and DNS names in the SAN
  3. _IF_ a CN includes a domain name or DNS name, then it _must_ be listed in the SAN

The first set of rules drop out of CA/Browser Forum Baseline Requirements (https://cabforum.org/baseline-requirements-documents/), CA/Browser Forum Extended Validation Guidelines (https://cabforum.org/extended-validation-2/), RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (https://tools.ietf.org/html/rfc5280), and RFC 6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (https://tools.ietf.org/html/rfc6125).

In practice, you should treat Rule 1 as forbidden.It does not affect operations of modern user agents. Ancient user agents may have trouble, but they are probably using SSLv2 and SSLv3, so they have bigger problems.

And some more rules:

  1. No IP addresses in the CN or SAN

This is more restrictive, and comes from RFC 6797, Appendix A, HTTP Strict Transport Security (HSTS) (https://tools.ietf.org/html/rfc6797) and RFC 7469, Public Key Pinning Extension for HTTP (https://tools.ietf.org/html/rfc7469). I believe the CA/B is going to adopt the policy (if it has not done so).

Rule 4 is tricky and it has me worried. An Enterprise running its own PKI often uses IP addresses, and developers testing on local machines often use IP addresses. Though IPs currently work, I'm worried the browsers might change their behavior on us.

If you are interested in an OpenSSL CONF file to build certificates against the rules above for testing, then see How do you sign Certificate Signing Request with your Certification Authority? on Stack Overflow. Its the same CONF file I use at work :) If its a developer machine for testing, then I add a bunch of additional names to the SAN, like localhost, localhost.localdomain, 127.0.0.1 and ::1.

jsha commented 8 years ago

Current plan:

In the long run, we will probably want to omit the CommonName field unconditionally, but in the short term this allows issuance of certificates with no CommonName, which can be tested for compatibility in the field.

noloader commented 8 years ago

In the long run, we will probably want to omit the CommonName field unconditionally, but in the short term this allows issuance of certificates with no CommonName, which can be tested for compatibility in the field.

This should work fine for all browsers and most other non-ancient user agents (maybe all?).

From experience, I reached out to Rob Stradling of Comodo for a free TLS server certificate for the Crypto++ website. Rob and I know one another from the OpenSSL project and the TLS working group. Comodo was happy to supply one for a free project.

I requested _CN=Crypto++ Project_, and _SAN=cryptopp.com, www.cryptopp.com, ftp.cryptopp.com, wiki.cryptopp.com_. Some wires got crossed, and the CN got dropped entirely. All the hostnames were placed in the SAN as expected. Crypto++ has never experienced a problem with it.

Below is the Crypto++ website certificate. Notice there is no _Subject CN_.

Ignore the "verify error:num=20..." message. It can be fixed with a _-CAfile option added to **s_client**_, but it adds no value here.

$ openssl s_client -connect www.cryptopp.com:443 -tls1 -servername www.cryptopp.com \
    | openssl x509 -text -noout
depth=2 /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            df:9c:47:64:aa:5f:b6:4e:39:11:d2:24:ef:b2:74:5f
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
        Validity
            Not Before: Sep 17 00:00:00 2015 GMT
            Not After : Sep 16 23:59:59 2018 GMT
        Subject: OU=Domain Control Validated, OU=COMODO SSL Unified Communications
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:c4:c5:ee:5b:99:51:25:15:3a:5e:1f:4a:97:9a:
                    dc:1f:c7:d1:4a:91:92:b3:31:b6:ef:4b:24:cf:dc:
                    79:9c:89:97:39:f7:19:dd:d6:60:5b:db:d3:bf:75:
                    d5:81:75:38:c3:45:03:83:af:e7:b6:68:09:2a:a8:
                    3b:30:08:60:ba:a7:e4:11:a9:37:7a:cd:f2:bb:23:
                    80:64:20:e5:24:c9:1b:bb:0c:39:ce:cf:93:54:ba:
                    79:57:4b:d0:85:ed:c0:a0:1b:85:aa:d4:a7:af:72:
                    2f:33:8a:0f:e4:37:22:f7:c9:ae:a6:05:a5:32:4f:
                    51:4c:5c:34:5f:2e:59:c1:69:d6:88:81:73:ba:a6:
                    41:98:ae:24:22:df:d1:57:ad:60:44:5f:e6:87:50:
                    95:34:1b:41:e0:b4:d9:be:00:57:4f:7d:c0:5c:8c:
                    d1:30:29:f9:ef:55:91:d4:ee:a3:6a:43:ca:84:be:
                    d8:99:22:db:74:c8:fa:14:b2:25:65:ba:01:be:3f:
                    9a:34:4a:b1:71:93:b8:87:0c:01:44:95:57:e5:a3:
                    5d:46:64:50:06:ce:36:32:f7:57:0b:02:f6:a8:5e:
                    dc:ab:95:b8:8e:b3:88:1d:bd:a9:56:18:15:00:0e:
                    8d:bf:7d:d4:76:8a:95:89:1f:ab:27:61:18:54:68:
                    eb:d3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:90:AF:6A:3A:94:5A:0B:D8:90:EA:12:56:73:DF:43:B4:3A:28:DA:E7

            X509v3 Subject Key Identifier: 
                01:5A:F4:9F:BE:DC:07:E8:DC:C9:4F:DB:52:41:18:2B:19:0F:CF:C3
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.6449.1.2.2.7
                  CPS: https://secure.comodo.com/CPS
                Policy: 2.23.140.1.2.1

            X509v3 CRL Distribution Points: 
                URI:http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl

            Authority Information Access: 
                CA Issuers - URI:http://crt.comodoca.com/COMODORSADomainValidationSecureServerCA.crt
                OCSP - URI:http://ocsp.comodoca.com

            X509v3 Subject Alternative Name: 
                DNS:cryptopp.com, DNS:ftp.cryptopp.com, DNS:wiki.cryptopp.com, DNS:www.cryptopp.com
    Signature Algorithm: sha256WithRSAEncryption
        75:41:b5:9a:44:87:86:ed:30:16:f1:a1:35:64:d0:0d:34:89:
        47:ab:7c:51:1f:e7:34:7d:43:b1:48:8d:67:00:7a:fa:ea:65:
        8b:3f:54:fc:a2:64:43:b5:86:fb:96:4d:d5:0b:eb:bc:2f:ca:
        5d:3b:99:60:c6:ec:de:35:66:4a:f2:55:9a:1f:f2:47:71:56:
        a6:6c:d5:f0:dd:60:a1:32:7d:fe:74:f8:af:54:a1:21:95:a3:
        30:f0:fa:51:57:79:c1:c5:e9:ef:71:39:a6:1e:4b:fd:31:82:
        d7:70:75:b2:8b:97:99:35:83:05:f3:e7:51:4a:3d:3d:02:f9:
        5f:48:64:b1:b6:f7:8c:9b:99:46:79:3c:3b:e3:c5:a0:f1:12:
        6d:6b:0b:8a:00:c5:3a:3f:b6:cc:61:30:f9:96:33:2b:09:e9:
        ef:17:33:2e:af:57:7b:d9:94:f6:3e:84:fc:a8:19:18:a5:62:
        4f:2e:ae:ec:ae:ed:24:0b:a9:55:5a:e8:e1:4c:70:34:f3:1a:
        5f:7d:fb:5f:d3:a0:85:de:24:3d:bc:53:92:00:ff:c4:9d:9b:
        6e:de:3d:f9:24:61:7f:a1:dc:e1:b6:bc:34:21:a4:95:f4:1d:
        d8:7b:f8:82:88:60:82:5d:8d:8b:b9:e4:41:6d:50:d2:0f:4f:
        9a:db:cd:b2