29

Say I have these URLs:

  1. https://example.org/

  2. https://example.org/criticalpath

I want the first one to be served with a domain validated commercial SSL certificate and the second one with an extended validation SSL certificate. Is it technically possible? Is it supported by SSL/TLS (and HTTPS?) standards and browsers?

I'm not asking in any way if this is even a good configuration (I would go for the EV for all the domain), I just need to know if that configuration is supported. I would really appreciate references to the standards.

Vilican
  • 2,703
  • 8
  • 21
  • 35
Jaime Hablutzel
  • 2,598
  • 3
  • 17
  • 17

3 Answers3

39

Yes and No.

It's possible to have multiple certs that all have the same domain name on it. You could have a Comodo example.org cert and an Entrust example.org cert, both of them valid and official, no problem. I believe some load balancers will rotate which one is used on a per-connection basis, but only in a round-robin fashion.

The No is that you're asking if you can select which cert to use based on the URI (/ vs. /criticalpath). The problem is, the URI is only available after the SSL connection has been nailed up using one of the two certs. So you can't really choose which cert to use based on information you can only have after you've chosen the cert.

Now, I'm not going to say 100% it's impossible. With Apache, for example, you can set the SSLCipherSuite configuration on a per-directory basis, so I wouldn't be surprised if there was some way to force a renegotiation that would involve a new cert. But I rather suspect it's practically unimplemented even if it is theoretically possible. (Apache SSLCertificate* is per-server or per-vhost, not per-directory).

Appendix: Musings upon renegotiation

Disclaimer: I haven't done any of this, it's a layman's interpretation of the RFCs and other documents. Dozens of people here are far more qualified to comment than I.

I'm going to look at TLS 1.2 since it's neatly described within RFC 5246.

Section 7.4.1.1, "The HelloRequest message MAY be sent by the server at any time." That should trigger the Client to renegotiate the connection. (The client MAY ignore that request, and the server MAY drop the connection if the client ignores the request for too long.)

A renegotiation looks very much like an initial negotiation, although it may pass some information from the previous negotiation forward to try and smooth the path (e.g., here's the cipher we agreed upon last time). So the Client sends a ClientHello, then the server sends a ServerHello, then the server sends a Server Certificate (7.4.2).

So my read of the RFC is that, yes, a server can force renegotiation of a connection, including the selection of a different server certificate.

I'll be honest with you, I don't know that you'll find existing software that will do what you want to do. I would suggest you start playing with Perl Crypto::OpenSSL or Python's ssl lib to see if you can test it out.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • I'm very insterested in the part of your answer where you say `if there was some way to force a renegotiation`, because after getting the actual URL path I could make that, it is forcing the renegotiation, but is it a SSL/TLS supported operation? – Jaime Hablutzel Dec 15 '13 at 21:01
  • I _think_ so, and have updated the answer (added **Appendix**) to lay out why I think so. – gowenfawr Dec 16 '13 at 00:58
  • 1
    A Web server _can_ start a renegotiation at any time, and that's exactly how IIS handles client certificates: it starts with a "normal" SSL handshake, then, when it learns the target path (HTTP request received), it may decide that, for that specific path, it needs a client certificate, and thus starts a new handshake (a renegotiation) by sending a `HelloRequest` message. That second handshake also involves a certificate from the server (not necessarily the same). A good question, though, is which server certificate (the first or the second one) the browser will show to the human user. – Thomas Pornin Jul 15 '15 at 17:10
  • 1
    I'm not sure on this. Wouldn't this (certificate change on renegotiation) be prevented by the [Triple Handshake](https://www.secure-resumption.com/) countermeasures (or at least by some of the browsers)? – SEJPM Jul 15 '15 at 21:12
9

Nope. No web server can support this feature; not now, not ever. Here's why:

HTTPS follows these steps in this order:

  1. Client connects to the server
  2. SSL/TLS negotiation (includes exchanging certificates, certificate verification, and encryption setup)
  3. Client sends request (includes server hostname, path, cookies, etc)
  4. Server sends back response (includes response headers, content, etc)

Note that step 2 above happens before step 3. That is, the whole encryption thing is totally finished before the browser tells the server what URL it's looking for. This means that when the server selects an SSL certificate to use, it does not yet know what the URL path will be. Since this information is not available at that stage, it can't factor in to the decision of which certificate to use.

Also note that the hostname is sent to the server in step 3, which is why each certificate is typically installed on unique IP addresses; the server uses the IP address to determine which certificate to present. Newer versions of SSL/TLS added extension called Server Name Identification to allow for the client to specify the hostname during TLS negotiation, but this only works for hostnames.

There is no provision to allow certificate selection based on the URL path, nor will there ever be, because that would imply that the URL path needs to be sent to the server unencrypted as part of certificate selection. And sending the URL unencrypted would be unacceptable for a secure page.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • I think that the feature to allow the client to specify the hostname before the server to present a certificate is actually really common, a simple SSL configured Apache named virtual host does it – Jaime Hablutzel Dec 15 '13 at 20:57
  • could you point to me to the SSL/TLS (or HTTPS?) spec where the step 3 is described? – Jaime Hablutzel Dec 15 '13 at 21:02
  • @jaime http://www.ietf.org/rfc/rfc2616.txt – tylerl Dec 16 '13 at 07:21
  • @jaime yes, putting multiple certificates on the same IP is getting more common, but it won't help you with your original question. – tylerl Dec 16 '13 at 07:31
  • 3
    If anybody wnats to look it up: The feature allowing to provide the hostname during TLS handshake is called "Server Name Indication" (SNI) – Drunix May 13 '14 at 11:09
3

I am thinking it may be possible using SSL offloading, deep packet inspection, and TLS renegotiation. However, if you google TLS renegotiation, the top 20 hits will be about renegotiation vulnerabilities-- so if you do it, you may end up making your site less secure, not more.

On the other hand, if your scheme were like this:

https://example.org/

https://criticalpath.example.org/

it would be pretty trivial. You'd just route those two domains to different internal IPs, and bind the IPs to different certs.

John Wu
  • 9,101
  • 1
  • 28
  • 39
  • 1
    With different domain names you don't need different IP addresses, one server can support multiple vhosts with different certs using SNI (Server Name Indication) -- as stated in tylerl's answer 3 years earlier. – dave_thompson_085 May 18 '19 at 09:03