Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

FF's X.509 decoding

The URI in the address bar - at the top - is the same URI in the certificate. I updated my hosts file to point to localhost. They cert is pretty much'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:


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?

share|improve this question
Also, if that's a valid subjAltName what should the id-at-commonName be? Since it's a self-signed cert the issuer and the subject should be the same. Could id-at-commonName be a URI as well and the subjAltName extension be deleted and the cert be just as (in theory) valid? – compcert Apr 21 '12 at 16:54
up vote 2 down vote accepted

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.)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.