Support for trusted_ca_keys extension during TLS handshake
david.fuhrmann at googlemail.com
Wed Oct 31 16:50:30 CET 2012
Am 31.10.2012 um 16:06 schrieb Martin Paljak <martin at martinpaljak.net>:
> On Wed, Oct 31, 2012 at 2:22 PM, David Fuhrmann
> <david.fuhrmann at googlemail.com> wrote:
>> I have the situation that an embedded system only has a limited and static
>> set of CA
>> certificates installed (at production time). For these CA certificates, it
>> is intended that you
>> can have newer ones with an overlaping validity period. So, the server needs
>> to know
>> which tls certificate he needs to deliver so that the embedded system can
>> verify it with
>> the existing CA certificate.
> 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.
The server has as much TLS certificates as root certificates exist (issued by these root certs over a chain). So as the client
want to validate the TLS certificate, and only has one root certificate, the server needs to send the one TLS
certificate which is issued by the root which exists in the client. In order to determine the right one, the client shall send the
existing root cert over this extension to the server before.
More information about the Gnutls-devel