URIs in the subjAltName X.509 extension

Question

The subjAltTag extension for X.509 certificates can take in domain names, email addresses, URIs, etc. I was playing around with an X.509 whose subjAltTag had just a URI in it doesn't seem to work. Here's a screenshot:

The URI in the address bar - at the top - is the same URI in the certificate. I updated my hosts file to point www.google.com to localhost. They cert is pretty much google.com's cert resigned.

My question is... why isn't it working? Do browsers only support domain names?

The X.509 certificate and its corresponding RSA private key are attached:

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQCaSBi+M4Gl/qWFOM24QrioNLplsW0MwLH/jDpWdckJIm979pPv/qUt6MUNgq7r
Di87poo6j8Ak726He6Br1bNJoRiTzHtbHqAFVgNp4Cxv5pade8zr4qBX8j9Pl76oq/MB2Yfcg7Rb
N/kblPBlsLwWNfrBt2nLZgn47pccUioNsQIDAQABAoGAFGJgOoktoRQDJJX7wFO4eCj3U8ZchSnU
mtIZRyEq3bUaC8PpifUYN/egSYexusbWAMihTNl/ZqHn9aik6nqCxIqYxgx9grybGOBo36qJzFSC
cszNWeEd1VAi7gJBHSZlSWhOrEHM0faYXh+DRisVTGSnmRsNIltu7Havf5KXua0CQQD9rJRF3lSB
ci3/d5c3Z+S52Lkv1zIvHhsFOYn39LCJVSUv9ufok5d2ktgFlYcVhsdr4La9ks4L8jQeiWQaWqiX
AkEAm7I5foaUX3P71dvaIH2fPXPLMF8h9jcK37YXTkaSeh1waKPUofSDcK2kJq86EZI3HA4bGVk9
QPvzmHGUzAI89wJBAMob0Pqlu+ByjzFmH+W18eccQ9dY9hPSQab1A/a5Tlnsq7c+WeDUjq2bK1+v
lbPR8VsC67W4nE+qRlo6DrZsmrsCQF36V+XdSdXL5miRybnu2Z14NV8/LPq3AqNCABNJWcTH3D/t
E72mH2h2By0qe3x7qzQN96F3UhfVfJW5iT0S5MUCQFhYfOylO4Yi13hpjOQb8M31sCKZUBUJIipP
c/8PFDyfJiTt61ZiMnYgIst5T2ai98S8+XZZwEvxNyu1uiQ2tbI=
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIDaDCCAtOgAwIBAgIBCTALBgkqhkiG9w0BAQUwazELMAkGA1UEBgwCVVMxEzARBgNVBAgMCkNh
bGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2dsZSBJbmMxGjAY
BgNVBAMMEXd3dy5mcm9zdGplZGkuY29tMB4XDTEyMDMyMTE2MzcyM1oXDTEzMDQyMTE2MzcyM1ow
azELMAkGA1UEBgwCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZp
ZXcxEzARBgNVBAoMCkdvb2dsZSBJbmMxGjAYBgNVBAMMEXd3dy5mcm9zdGplZGkuY29tMIGdMAsG
CSqGSIb3DQEBAQOBjQAwgYkCgYEAmkgYvjOBpf6lhTjNuEK4qDS6ZbFtDMCx/4w6VnXJCSJve/aT
7/6lLejFDYKu6w4vO6aKOo/AJO9uh3uga9WzSaEYk8x7Wx6gBVYDaeAsb+aWnXvM6+KgV/I/T5e+
qKvzAdmH3IO0Wzf5G5TwZbC8FjX6wbdpy2YJ+O6XHFIqDbECAwEAAaOCASAwggEcMAwGA1UdEwEB
/wQCMAAwOQYDVR0fAQEABC8wLTAroCmgJ4YlaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVNH
Q0NBLmNybDArBgNVHSUBAQAEITAfBggrBgEFBQcDAQYIKwYBBQUHAwIGCWCGSAGG+EIEATB1Bggr
BgEFBQcBAQEBAARmMGQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLnRoYXd0ZS5jb20wPgYIKwYB
BQUHMAKGMmh0dHA6Ly93d3cudGhhd3RlLmNvbS9yZXBvc2l0b3J5L1RoYXd0ZV9TR0NfQ0EuY3J0
MC0GA1UdEQEBAAQjMCGGH2h0dHBzOi8vd3d3Lmdvb2dsZS5jb20vYXNkZmFzZGYwCwYJKoZIhvcN
AQEFA4GBAEWifm73z2rOJd9Io7egHEFRG+GNpUi+owYnSM07cStlwKg0UXesKxEO9Pud942WqwIt
TJUpYuUWyLupMh7R5ZfbrYsFfohwKqctKZLt/0+Lup2SNHDk79mJ0bsEql7ktMmSCSVE7AHt4j2t
hYm2aSTho/PLcjknV7Ul60csqVXJ
-----END CERTIFICATE-----

Here's the specific errors Firefox is giving me:

The certificate is not trusted because it is self-signed.
The certificate is not valid for any server names.

Any ideas?

Answer 1

When making an HTTPS connection, the rules used to verify the server's identity are still those given in RFC 2818 (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.

[...]

In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.

In your certificate, no Subject Alternative Name (SAN) extension of type DNS (dNSName) is present. Hence, it falls back to the Subject DN's Common Name.

A more recent specification (RFC 6125) harmonises the host name verification procedure across other protocols. However, it is not widely implemented yet.

It allows for the use of URIs, and says this (amongst other things):

[...] Therefore this document discusses Uniform Resource Identifiers [URI] only as a way to communicate a DNS domain name (via the URI "host" component or its equivalent), not as a way to communicate other aspects of a service such as a specific resource (via the URI "path" component) or parameters (via the URI "query" component).

Essentially, only the scheme and the host name are really used from that URI. This means it's only more specific than a DNS SAN entry by limiting the usage to a certain protocol (not even the port as far as I can tell from a quick read).

This specification was only finalised about a year ago, which isn't that long. It's not clear how widely it will be adopted. For clarification and harmonisation of existing practises, it's certainly worth the effort, but I guess CAs and implementors would need to know it better and find a demand for issuing certificates with URI SANs, since it doesn't map to the specification previously used (RFC 2818). I guess there would be little demand from service providers, since few clients support it anyway.

Many browsers don't fully implement RFC 2818 as it is (being more lenient on IP addresses in the CN of the Subject Name, without SAN, for example).

(As a side note, from a client-certificate point of view, you may be interested in the WebID project, which explores other ways than PKIX of verifying a client-certificate and make use of URIs in the SAN.)