It may be better to match the SubjectAltName (SAN) rather than the CommonName in the TLS certificate

[daidoji]

I was reading through the new version of the spec and it jumped out at me:

The domain name element of the method-specific identifier MUST match the common name used in the SSL/TLS certificate, and it MUST NOT include IP addresses.

Although the CN conceptually seems like the best field to check, I think Internet history and some ambiguity in how Netscape used the x509 specification way back in the day led to the modern browser behavior of checking the SAN as the authoritative domain identifier on a certificate. Probably better to follow the browser convention for this did method unless there was a particular reason to choose CN validation for this did method that I don't understand. (Although the most secure would be to do what's advised in the answer and check Subject, CN, and SAN.

See this stack overflow and the RFCs mentioned in this answer for details: https://stackoverflow.com/a/5937270/488228

[swcurran]

Interesting. Indeed, based on the description the SAN is the right way to check. I think what the requirement is really saying, although done so in a roundabout way, is that the URL MUST use the HTTPS protocol, and MUST NOT include IP addresses. I would think it would be better to just say that, and not get into the details of how SSL/TLS certificates work.

Reasonable?

I’ll put in a PR after the current v0.4 PR is merged. Or feel free to put one in if you want.

[swcurran]

Ideally we point the SSL spec and remove the precision of the reference. What we are trying to say is "Use SSL in the way modern browsers use SSL". @swcurran