Issue without CN about boulder HOT 9 CLOSED

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.

from boulder.

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.

from boulder.

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.

from boulder.

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

from boulder.

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

from boulder.

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

from boulder.

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.

from boulder.

Current plan:

• Include the SerialNumber field in the Subject section on all certificates (matching the serial number of the certificate).
• Set the CommonName field in the Subject section if and only if it is set in the CSR and has a valid authorization. Also ensure the same DNS name is included in the SAN. Difference from current code: currently we will choose a SAN to stick into the CN field, even if the CN field isn't set.
• If a CSR requests a CommonName longer than 64 bytes, reject the request.

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.

from boulder.

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

from boulder.