Why am I getting URL mismatches on my wildcard self signed certificate?

Question

I'm trying to set up a self signed wildcard certificate for use by Apache, normally this is pretty straightforward I just set a subjectalternate name with the root domain and specify *.dcrdev.com in the common name field. However it seems this is not working - when I try and access the site in chrome or test it in sslabs they report URL mismatches when accessing any subdomain such as www.dcrdev.com or subdomain1.dcrdev.com. I'm not sure why, when I view the certificate information in chrome it shows the common name as *.dcrdev.com.

My csr:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/emailAddress=webmaster@dcrdev.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                lah blah

My certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1048577 (0x100001)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Root Authority, CN=*.dcrdev.com/emailAddress=administrator@dcrdev.com
        Validity
            Not Before: Oct 13 23:41:03 2015 GMT
            Not After : Oct 10 23:41:03 2025 GMT
        Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/emailAddress=webmaster@dcrdev.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
               Blah blah
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                83:2D:84:F1:E2:B0:72:30:E6:3B:6A:F6:8E:6A:68:8E:3F:D4:69:44
            X509v3 Authority Key Identifier: 
                keyid:F5:A6:82:E2:DD:52:10:CE:FD:C5:C7:E1:E9:CF:C6:8C:30:26:D7:DC

            X509v3 Subject Alternative Name: 
                DNS:dcrdev.com
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
    Signature Algorithm: sha256WithRSAEncryption
        Blah blah

Answer 1

Crossdupe of https://stackoverflow.com/questions/3093112/certificateexception-no-name-matching-ssl-someurl-de-found .

Subject Common Name is no longer controlling for HTTPS certs.

AFAICT there isn't actually a standard saying so, but practice for some years now is that browsers etc use the SubjectAlternativeName (SAN) extension if it is present, and CommonName (CN) in Subject only if SAN is absent. Your cert has SAN present with dcrdev.com, so only that matches.

update: found in RFC2818 3.1 :

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

That RFC was May 2000, but to my recollection the certificates I encountered didn't start using SAN until closer to 2010. The more recent March 2011 RFC6125 identified by @JennyD (does it work in body of answer?) is a more general treatment, but explicitly says

This document also does not supersede the rules for verifying service identity provided in specifications for existing application protocols published prior to this document, such as those excerpted under Appendix B.

and appendix B includes RFC2818.

The Baseline Requirements from CA-Browser Forum do say that CAs must issue certs with SAN while Subject.CN is deprecated, although that's not directly a requirement on browsers/clients.

If you want to use both the domain and subdomains (one level only), put two dnsName entries in SAN, one for dcrdev.com and one for *.dcrdev.com.