Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Say I have these URLs:

  1. https://example.org/

  2. https://example.org/criticalpath

And I want that 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.

share|improve this question

2 Answers 2

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.

share|improve this answer
    
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 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 0:58

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.

share|improve this answer
    
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 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 Dec 15 '13 at 21:02
    
@jaime ietf.org/rfc/rfc2616.txt –  tylerl Dec 16 '13 at 7: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 7:31
    
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 at 11:09

Your Answer

 
discard

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.