1

I have a web service which is secured through HTTPS. I also have client software which talks to this web service, using libcurl (which may be linked to OpenSSL, or linked to GnuTLS; I don't know which one, it depends on how the user installed libcurl). Because the web service is only ever accessed through the client software and never through the browser, the web service utilizes a self-signed certificate. The client software, in turn, has a copy of this self-signed certificate and explicitly checks the connection against that certificate.

Because of Heartbleed, I want to change the private key and certificate. However I want my users to experience as little service disruption as possible.

For this reason, I cannot change the key/certificate on a fixed date and time. If I do this then all users must upgrade their client software at that exact date and time. Otherwise, the upgraded client software won't work before the server change, while old versions of the client software won't work after the server change.

Ideally, I want to tell my users that I'm going to change the certificate in 1 month, and that they have 1 month time to upgrade the client software. The client software should be compatible with both the old and the new certificate. Then, after 1 month, I can issue another client software update which removes support for the old certificate.

So now we've come to my question: can I append the old certificate and the new certificate into a single .crt file? Will this cause libcurl to accept both certificates? If not, what should I do instead? Does the behavior depend on the SSL library or version?

Tests on OS X seem to indicate that appending both certificates into a single file works, but I don't know whether this is OS X-specific behavior, or whether it works everywhere. My client software has to support a wide range of Unix systems, including Linux (multiple distros) and FreeBSD.

Hongli
  • 18,682
  • 15
  • 79
  • 107
  • The answer to http://stackoverflow.com/questions/9879688/difference-between-cacert-and-capath-in-curl seems to indicate that whether your file can contain multiple certificates depends on how your client uses curl. I think you can extract an answer one way or another from that, since you can always change how your client uses curl. – Warren Dew Apr 20 '14 at 03:27
  • @WarrenDew On the server side, concatenating multiple certificates together indicate a certificate chain. The concatenation even has to be done in a specific order. Do things work differently on the client side? Do both OpenSSL and GnuTLS consider client-side certificate concatenation to mean "here are multiple certificates, pass if any of them match"? That topic doesn't seem to explicitly answer this question. I'm a bit wary about whether there are differences in behavior between OpenSSL and GnuTLS, or even different OpenSSL versions. – Hongli Apr 25 '14 at 08:11
  • I think that question is about curl, not about OpenSSL and GnuTLS. I'm not a curl expert, but as best I can tell, one option for having a library of multiple certificates in curl is to just have them together in one file, as opposed to how Java has them stored (encrypted) in the cacerts file. By the time they're presented to OpenSSL or GnuTLS, they've been extracted into single certificates, I expect. – Warren Dew Apr 25 '14 at 08:59

3 Answers3

2

Short answer: You can't.

Long answer:

Yes you can put multiple certificates in a single .crt file, regardless of platforms.

However HTTPS can only serve one certificate, instead of a crt file. So it's not the file that is limiting you, it's the protocol.

Sheepy
  • 17,324
  • 4
  • 45
  • 69
  • I'm not talking about my server serving multiple certificates. I'm talking about my clients accepting multiple alternative certificates. – Hongli Apr 25 '14 at 08:09
  • @Hongli For your client to be able to choice from multiple certificates, there must be multiple certificates offered in the first place. That being said, if the client is (re)validating a crt file transferred AFTER https is **accepted** and established, then yes it will work. – Sheepy Apr 25 '14 at 08:24
0

You could have a look at SNI https://en.wikipedia.org/wiki/Server_Name_Indication to be able to serve another certificate based on the SNI information sent by the client at the beginning of the SSL Handshake

Alternatively, you could use a separate TCP port (or IP, or both) that will serve the new certificate.

But you say

The client software, in turn, has a copy of this self-signed certificate and explicitly checks the connection against that certificate.

This then requires you to release a version of your software for your clients to run, to at least have the copy of the new certificate you are going to use.

I guess you should better use a certificate signed by well-known CA, to decouple your server certificate from its validation chain, but that indeed means paying.

Julien
  • 1,765
  • 20
  • 26
-1

Yes a cert file should be able to hold multiple certificates. I would expect this to be broadly supported.

Patrick O'Hara
  • 557
  • 1
  • 6
  • 17
  • Source? And are you sure? On the server side, concatenating multiple certificates together indicate a certificate chain. The concatenation even has to be done in a specific order. Do things work differently on the client side? Do both OpenSSL and GnuTLS consider client-side certificate concatenation to mean "here are multiple certificates, pass if *any* of them match"? – Hongli Apr 25 '14 at 08:10
  • What source would you consider authoritative? The issue is that there is no standard body for how clients are implemented. How else would a seamless transition from one cert to another work? I know that I have done this on various Unix systems (NOTE: Not Linux but HPUX, AIX, Solaris, etc.) You mentioned that this works on OS X (Free BSD Based). Windows is the last question mark. I know the cert tools on windows where originally based on Unix tools, so I am confident it will work there also. – Patrick O'Hara Apr 25 '14 at 09:46
  • Well, a libcurl/OpenSSL/GnuTLS developer answering how certificate checking is implemented, or a reference to the line of code that implements said behavior, or maybe a blog post that demonstrates that behavior is consistent between all those libraries, would be considered authoritative. – Hongli Apr 25 '14 at 11:47
  • After testing, it turns out that concatenating multiple client certificates into a single file works as expected. Tested on Ubuntu 14.04 with: 1) libcurl linked to OpenSSL 2) libcurl linked to GnuTLS 3) curl + OpenSSL 4) curl + GnuTLS 5) wget + OpenSSL 6) wget + GnuTLS. The order of the certificates does not matter. – Hongli May 05 '14 at 12:37