Support for trusted_ca_keys extension during TLS handshake

David Fuhrmann david.fuhrmann at
Wed Oct 31 18:40:02 CET 2012

Am 31.10.2012 um 18:32 schrieb Nikos Mavrogiannopoulos <nmav at>:

> On Wed, Oct 31, 2012 at 4:50 PM, David Fuhrmann
> <david.fuhrmann at> wrote:
>>> Does this mean that you would have two overlapping CA
>>> keys/certificates, with the same name but different validity periods?
>>> This sounds like a strange setup to me. Why can't the client system
>>> differentiate the (updated) issuer itself, by changing the common name
>>> of the new root?
>> How naming is handled doesn't matter here.
>> The problem is, that the client has (in the simplest case) only one CA / root certificate, and also no internet
>> connection or any possibility to update this root certificate.
>> Now after specified intervals, a new root certificate is created, to have a fresh one to be installed into newer clients.
>> So, every Client has a root certificate, which has a validity of minimum x years.
> I don't know whether you can apply it in your case, but why not use
> the "traditional" PKI there. Have a root CA to sign all other temporal
> CAs and have all the devices to trust the root one. It sounds more
> elegant approach than having the server decide which certificate to
> use based on the connecting client trusted CA.

Yeah, sure, but the root certificate to be installed inside the client already lasts 40 years.
The system is to be designed to work longer than that, and it not so a good idea to create an even longer "super" root CA.


More information about the Gnutls-devel mailing list