If I have a valid (verifiable) certificate C_K_s that links the server key K_s to "www.example.com", is it possible to :

  • use K_s to sign K_d, and let S_K_d be this signature
  • use K_d as the TLS server key

when a TLS client connects, I would:

  • show C_K_s to establish that the official key is K_s
  • then during session key negotiation:
    • show S_K_d to establish that the actual key is K_d
    • sign the pairwise private key, or server DHE key, with K_d

I want TLS clients to tell users that the server key is K_s.

K_s is the key I will print, that users can check, etc. (Users do not need to know about K_d.)

  • s is for static: K_s would rarely change, can be stored off-line and/or stay encrypted. For example, in a secured configuration, K_s could be stored in a special mass storage that can only be read once after each reboot (I believe this property can be obtained f.ex. with a TPM).
  • d is for dynamic: K_d can change often, must be in clear-text in server memory at all times.

I just want to be able to change my real server K_d as often as I want, without either the CA, Perspective, some "SSL Observatory"... knowing about it because the official signing key is really K_s. The official certificate is C_K_s so Certificate Patrol should not store only C_K_s and not tell when C_K_d changes.

Would it be possible to emulate this behaviour using a fixed (precomputed) DHE key as K_d?

Clarification about the term "certificate"

I used the term "certificate" for the validation of K_d using K_s, and this unfortunate wording has created some confusion.

The TLS server would only possess K_d (not K_s), so a link between K_s and K_d is needed, and I called that link a "certificate", but it is just a signature of K_d by K_s.

  • What do I have to read in order to understand this question? ;) I'll take any links you suggest. Are you assuming working knowledge of how TLS negotiation works? Now that I see your update this doesn't appear to be a PKI question on End Entities... (or is it?) Commented Jun 18, 2012 at 0:45
  • Following your edit, note that there is never any point signing just a pub key (see this question): you always sign the association between the key and something, which effectively makes the result a cert. Overall, it's not clear what your scheme would improve compared with using the key in the cert directly: losing the private key for K_d would still allow an attacker to impersonate your server, without the private key for K_s, unless you end up implementing what would equate to a complex PKI system (including mechanism for revocation).
    – Bruno
    Commented Jun 18, 2012 at 11:31
  • @Bruno I could say: "by that the signature, the signer certifies that..." Of course any signature certifies a statement of fact, but here C_K_s is a regular TLS/X.509 certificate, and S_K_d need not all these attributes. During RSA_DHE, does the DHE key verification involves a certificate signing the DHE key?
    – curiousguy
    Commented Jun 18, 2012 at 13:16
  • @makerofthings7 "Are you assuming working knowledge of how TLS negotiation works?" Not really, superficial knowledge about TLS connection establishment should be more than enough (I don't have a really deep knowledge of the TLS protocol either). I will edit my question again to make clearer.
    – curiousguy
    Commented Jun 18, 2012 at 13:19
  • @curiousguy, yes the DHE parameters are signed (together with the hello random value) using the server's private key (matching the server cert), see Appendix F.1.1.3 (link in my answer). Unfortunately, superficial knowledge of TLS will not be enough. (How far are you willing to modify client SSL/TLS stacks for this, btw?)
    – Bruno
    Commented Jun 18, 2012 at 13:42

2 Answers 2


Certificates have a purpose field. So if you let a well known certification authority sign your server key, the resulting certificate will only be valid for servers.

In order to sign other keys, you need to get a certificate with the certificate signing purpose. In theory there is an extension which limits CAs to a domain, but it is hardly used. Therefore there are very high requirements for CAs.

  • I only want to use the K_s TLS key to authenticate a TLS key exchange with a TLS client. With TLS, an RSA key can be used to sign a private key directly, or a DH key, or (as Bruno says) another RSA key according to RFC 4346... in any case, the aim is to obtain a shared private secret between a TLS server and a TLS client, just with a additional intermediate level. How is that not the normal purpose of a server key?
    – curiousguy
    Commented Jun 15, 2012 at 23:06
  • @curiousguy, Hendrik is referring to certificate validation according to RFC 3280/RFC 5280, which is normally used by browsers. That's what validates the certificate chain, and says what the keys in the certificate may be used for (it's mostly from an administrative point of view, but that's the point of the PKI). There are key usage extensions and so on. Here, it's the basic constraint extension that you'd need for your cert to be a CA cert, being able to issue your temporary certs (although that's not exactly what you seem to want to do).
    – Bruno
    Commented Jun 16, 2012 at 11:20
  • @Bruno Yes, I understand that I could have an intermediate certificate that's essentially a CA for only one domain, with about the same powers has a *.domain cert, and this is exactly what I do not want. I want the certificate for my domain to indicate K_s and nothing else, and to introduce K_d not before the process of pairwise key agreement.
    – curiousguy
    Commented Jun 17, 2012 at 23:26
  • My question was perhaps badly worded, I am editing it.
    – curiousguy
    Commented Jun 17, 2012 at 23:27

What you're describing sounds similar to the use of temporary RSA key exchange, as described in Appendix F.1.1.2 of RFC 4346 (TLS 1.1) (also in RFC 2246, TLS 1.0).

I have never seen it used (but others may have). However, there seem to be a few inconsistencies in the specification on this subject. In particular, this appendix says that "[it] may be a temporary RSA key sent in a server key exchange message", but Section 7.4.3 (Server Key Exchange Message) says: "It is not legal to send the server key exchange message for the following key exchange methods RSA, DH_DSS, DH_RSA", which leaves the DHE cipher suites (and DH_anon). I must admit I'm not quite sure how this would work then, considering that with DHE_RSA and DHE_DSA, the DHE parameters are still signed using the certificate's key. This may explain why the mention of temporary RSA keys has disappeared from TLS 1.2.

Your other suggestion, about fixed DHE parameters, removes the "ephemeralness" of DHE, so that's rather about fixed DH; not all stacks support it. In addition, you'd still want the RSA/DSA key in the certificate itself to be used for the authentication anyway.

More fundamentally, it sounds like the potential vulnerability you're trying to prevent is someone stealing your certificate's private key.

  • Firstly, you may find you still need a way to revoke C_K_d, should its private key be compromised too. You don't necessarily gain that much using a scheme like you describe.
  • Secondly, "[...] stored in a special mass storage" sounds like you have access to the hardware and could potentially plug something in. Instead of twisting TLS like you're suggesting, I'd suggest using a Hardware Security Module: there are cryptographic tokens/smart cards from which the private key cannot be extracted, it can only be used on-board. You might have to leave the PIN code in clear in your server configuration, but at least the private key will never be copied, so if you suspect foul play, just unplug the device. (I've managed to run a Java-based SSL/TLS server using such a token and a PKCS#11 provider in the past. I'm not sure how this can be configured with other servers, but this is possible in principle.)


Just a bit of background about how SSL/TLS is used. There are essentially 3 categories of specifications involved:

  • SSL/TLS itself. Depending on the version this will be RFC 2246, 4346 or 5246. This describes how the protocol itself works (including the handshake). You could include in this category other RFCs that define additional cipher suites (e.g. Kerberos or EC).
  • Certificate validation/verification. Assuming X.509 certificates are used (as it is the case for HTTPS communications, see RFC 2818), clients rely on RFC 3280/5280. This defines how the client evaluates whether it considers a certificate genuine, trusted and valid for this purpose.
  • Host name verification. RFC 2818 Section 3.1 or RFC 6125: this defines how the client should decide whether the server certificate matches what the client was looking for.

As I was saying above, I don't think what you're trying to do can be done out of the box with these specifications.

It's not quite clear to me whether you're more after modifications involving the TLS Server Key Exchange message (so tweaking TLS itself) or new certificates (more along the lines of tweaking the certificate validation/verification step). It's easier to do the latter (both in theory and in practice), although both can be risky.

Since it seems that the problem you're trying to fix is the theft of your server private key, you may be interested in RFC 3820 (not to be confused with RFC 3280), which defines proxy certificates. Essentially, you can use an End-Entity Certificate (that is not a CA certificate) to issue a proxy certificate, usually with a much shorter validity period (e.g. 24 hours). This tends to be used in the Grid world to delegate authentication credentials, when connecting as a client. This aims to address the problem of potentially vulnerable private keys (on the machines where you delegate your credentials). I've never tried it from a server point of view, but it could work in principle. Apart from the generation of this proxy certificate, this approach wouldn't require many changes on the server side (they're X.509 certificates with a few specific attributes). However, this would still require changes on the client side to trust these certificates, since it would break RFC 3280/5280. (You can make modern versions of OpenSSL recognise such certificates.) This wouldn't work with most browsers out of the box.

At least, proxy certificates have a time limit. It's not clear how other schemes that you may be suggesting would help against the theft of private key. If you don't have a mechanism to revoke your temporary key/cert, the vulnerability would still exist, since a spoof server having one of your temporary private key could still impersonate your real server forever.

Considering the threat you seem to be worried about, a HSM still sounds like the best option, and it would work with existing stacks without tweaking the standards normally used.

  • Proxy certificates: I never heard of them, and they might be what I am looking for, so I will consult the links you gave. Thank you for your time and explanations anyway.
    – curiousguy
    Commented Jun 20, 2012 at 7:58
  • @curiousguy, proxy certificates will not work out of the box with browsers at all. When you say above "The only way seems a short-lived key": again, it's not, a better protection against the attacks you have in mind is to use an HSM and make the private key read-only.
    – Bruno
    Commented Jun 20, 2012 at 10:05
  • "proxy certificates will not work out of the box with browsers at all." at least the concept is interesting... "again, it's not, a better protection against the attacks you have in mind is to use an HSM" if you have one
    – curiousguy
    Commented Jun 20, 2012 at 13:51
  • I thought HSM was a viable option since you were talking about extra hardware (including TPM). Depending on your budget, here is an example that might not be too expensive. I've managed to run a Java web-server on a Linux box using the OpenSC PKCS#11 provider with an Aladdin eToken Pro 32K USB in the past. There are other models you could investigate. It's by far more viable than expecting every client browser to be compiled to support proxy certificates (unless you're in a very limited environment).
    – Bruno
    Commented Jun 20, 2012 at 14:19
  • "I thought HSM was a viable option since you were talking about extra hardware (including TPM)." In my question the use of specific hardware was just an example of a configuration where my proposed intermediate key might be beneficial for increased security. According to what you say, the only way to truly increase server secret key security is a specialised security token, so I will investigate that.
    – curiousguy
    Commented Jun 20, 2012 at 16:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .