[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-users
Subject:    RE: Supporting oldwithold, newwithnew CA certificates Reg.
From:       "Dave Thompson" <dthompson () prinpay ! com>
Date:       2011-12-29 4:46:25
Message-ID: 89398402CF504B5588297683CD802F24 () prinpay ! com
[Download RAW message or body]

>	From: owner-openssl-users@openssl.org On Behalf Of Ashok C
>	Sent: Tuesday, 27 December, 2011 06:20

>	But regarding this:
>	>>Important note: make sure the old and new root certs have
different
>	names. (Same for intermediate CAs, which your example doesn't have.)
>	OpenSSL looks-up using Issuer name only. <snip rest>
>	
	
>	I actually tested this particular scenario in my testbed and found 
> that it is not necessary that the old and new CA certs have different 
> names. <snip scenarios>

The last time I tried a rollover with the same name, it did fail for me, 
but that was quite a few years ago. Possibly something has changed since.
I don't have time to retest now. If it works for you fine.

>	One more clarification:
>	>>If OpenSSL client has cert-and-pkey configured and receives
CertReq,
>	it sends that cert regardless of any CAlist the server asked for;
>	that cert may be accepted or not depending on the server. And if
>	callback or engine is used it appears (but I haven't tested) that
>	can similarly select any cert regardless of what the server asked.
>	>>
	
>	Are you indicating here that the client can have multiple end entity

> certificates? Till now I had the assumption that the server/client can 
> have only a single end entity certificate. 

Yes. There are several good reasons for multiple certs (and keys).

1. (Really) different CAs e.g. server A accepts only certs from a 
private/internal A-CA that enforces company-A rules about which clients 
get certs, but client also connects to server B in a different company 
which understandably won't rely on A-CA and demands a "public" CA 
or even a similar but different private/internal B-CA. Similarly but 
less often a server may use an internal-CA cert for internal clients 
who know about and trust that CA, but a public one for other clients.

2. Different algorithms: server has one key-and-cert for RSA suites 
and different one for DSS (DSA) suites and maybe a third for ECDSA, 
and client similarly. In years past this was sometimes a political 
issue: systems in or connected to the US government were required 
to use DSA and not RSA, and some people in other places who didn't 
like the US government would use RSA but not DSA (including places 
where the US-issued patent on RSA wasn't enforced). Today this has 
died down and pretty much everybody trusts everybody at least for 
the cryptography, although there are still some places where ECDSA 
(and ECDH) aren't yet implemented versus others which insist on them 
because of bandwidth or power concerns e.g. mobile devices. 

3. Rollover/replacement much like your scenario; sometimes it 
isn't possible to "cut" a new CA (generation) all at once and 
there is a transition period where e.g. client needs new-cert for 
server A but old-cert for server B which hasn't been updated yet. 

4. Or you can do it just because you want to; the protocol only 
requires *a* server cert (unless anon) and *a* client cert (if 
client-auth used) that work, it doesn't care what others exist.

> Also, if the server can ask client to send selective certificates, 
> wouldn't it be applicable that the client also can request the server 
> for specific certificates? 

The original (SSL) protocol didn't provide for this beyond the 
algorithm selection inherent in the Client/ServerHello exchange.
OpenSSL server can be configured with all three algorithms and 
will use whichever one (first) agrees with the client request; 
I'm not sure if OpenSSL client can offer more than one (I have 
never needed to try that).

TLS extensions (RFC3546 in 2003, but optional in OpenSSL 
until about 2008 as I recall) adds among other features:
- ClientHello can specify "logical" server name; in particular 
for HTTPS this is the domain name from the URL, useful in cases 
where a single actual server supports multiple "virtual" hosts. 
- ClientHello can specify "trusted CA keys", either as a CA DN 
or several other methods.
- EC (RFC4492 in 2006) adds extensions to limit the curves 
and formats the client supports, which if the server disagrees 
should result in not selecting an EC suite (and if no other 
suites are shared, handshake failure).
 
> Are there separate openSSL APIs for this or we have to use the same 
> family of ssl_ctx_set_client* family of APIs for this purpose also?

For restricting cipher algorithms, *_set_cipher_list.

For the server-name extension, SSL_set_tlsext_host_name in client.
In server you provide a callback, with arg, to handle reception.

OpenSSL apparently does not implement the explicit "CA keys" 
extension, and I don't know if anyone else does either.

I haven't tracked through completely, but I believe OpenSSL 
always uses the correct values for EC curves and formats, 
i.e. OpenSSL supports what it supports and you don't change it.
(You can of course choose to not use EC suites at all.)


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majordomo@openssl.org
[prev in list] [next in list] [prev in thread] [next in thread]