Les entrées sont typées : dNSName (example.com, *.example.com), iPAddress (4 ou 16 octets), rfc822Name pour S/MIME, uniformResourceIdentifier pour les ID SPIFFE et similaires, et otherName pour des valeurs comme les UPN Microsoft. La correspondance des noms d’hôte suit la RFC 6125, mise à jour par la RFC 9525 : un caractère générique remplace exactement un label, celui le plus à gauche, si bien que *.example.com couvre www.example.com, mais ni example.com ni a.b.example.com.
Chrome ignore le commonName du sujet depuis la version 58 (2017) : la validation d’un certificat dont le nom ne figure que dans le CN échoue avec ERR_CERT_COMMON_NAME_INVALID. Les clients Go, Python et OpenSSL exigent eux aussi le SAN pour les noms d’hôte. Un certificat au sujet vide doit marquer le SAN comme critique (RFC 5280 §4.2.1.6).
Les certificats TLS publics peuvent contenir de nombreux SAN ; chaque nom doit être validé séparément et tous sont publiés dans les journaux CT (Certificate Transparency) : c’est pourquoi les noms d’hôte internes présents dans des certificats publics deviennent publics.