4

I have a requirement to limit SSL certificates by source IP.

Would setting a critical SubjectAltName limit this (server side validation is by OpenSSL via nginx)? If not, how could this be implemented?

2 Answers 2

8

No. SubjectAltName gives alternative names, so it means that the certificate is good for the Subject name and also for any name listed under SubjectAltName. It does not create an additional requirement to be met, it gives an alternative requirement to be met.

So a server-side certificate with alternative names "www.example.com" and "192.168.1.5" would be considered valid for https://192.168.1.5/ OR https://www.example.com/. Both criteria do not have to be met, only one of them.

However such a certificate would not match url https://test.example.com/ even if the IP address of test.example.com was in fact 192.168.1.5. Only the name as it appears in the URL is checked.

To limit use of a certificate to a particular IP, you need to implement your own restrictions, probably at the application level. I.e. you will have to write code which checks the client IP and the certificate and validates that the rules are complied with, returning a suitable HTTP status code if not.

1
  • 6
    Extra note: when there is a Subject Alt Name extension, SSL clients are supposed to ignore the contents of the Subject DN. That is, for HTTPS, the "alt names" replace the DN instead of complementing it. Jan 14, 2014 at 14:33
3

What you do with a client certificate is entirely up to the server. There is no standard rule. You may decide, server-side, that a given client certificate is acceptable only if the connection comes from a specific IP address; this depends on what the server code supports, not on the certificate contents.

For the server certificate, that one is validated by clients, and clients follow (more or less) the rules given in RFC 2818. This means that the clients expect the server name (as it appears in the target URL) to be present in the server's certificate, in its Subject Alt Name extension (if there is no such extension, clients will look at the Common Name in the subject DN). Only names are matched (of type dNSName); though the SAN extension can contain IP addresses (of type iPAddress), such addresses are not considered by HTTPS clients.

(There is a theoretical exception: if the URL contains not a name but a representation of an IP address, e.g. in "decimal-dotted", then that IP address shall match an iPAddress name in the SAN extension. Only an exact match is allowed; there is no wildcard-like matching. dNSName names are then ignored. This possibility is specified in RFC 2818 but it is unclear whether existing browsers implement it; it is known that browsers don't follow the rules exactly, in particular they implement only a limited subset of wildcards. In any case, I have never seen that used in the wild, and it would not be flexible, since IP addresses are a commodity subject to change, which is why the DNS was invented in the first place.)

Whether the extension is critical or not does not matter. When an extension is critical, then any system which processes the certificate must reject it altogether if it does not understand the extension. But the extension semantics are not altered by the criticality. Since all reasonable HTTPS clients (and servers, when they request client certificates) support the SAN extension, making it critical changes absolutely nothing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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