> To be clear, I *don't* mean SNI, I mean subjectAltName (SAN) validation.
Ah, apologies for the SNI/SAN confusion. However, I still cannot reproduce this failure when verifying peers with certs utilizing the SAN extension. Could you supply a code snippet demonstrating this failure? On Thu, Sep 19, 2013 at 2:23 AM, Ryan McCue <li...@rotorised.com> wrote: > Daniel Lowrey wrote: > > This is incorrect. PHP has supported both the "SNI_enabled" and > > "SNI_server_name" > > SSL context options since 5.3. Anything older than 5.3 is not remotely > > worth worrying over. You can verify this for yourself using the following > > code: > > To be clear, I *don't* mean SNI, I mean subjectAltName (SAN) validation. > > The common name field (CN) contains the domain name for normal > certificates, but you can have more than one domain per certificate. If > you do that, it's stored in the subjectAltName (SAN) field. PHP only > parses the CN, not the SAN, so any domain that isn't the main domain in > the CN will fail. > > As per RFC 2818 (http://tools.ietf.org/html/rfc2818#section-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. > > > -- > Ryan McCue > <http://ryanmccue.info/> >
