> From: owner-openssl-us...@openssl.org On Behalf Of nicolas....@free.fr > Sent: Friday, June 13, 2014 06:15
> the fact is a server can only send a single certificate, however this one can > be > signed by multiple CAs Kind of. There's a difference between what we humans perceive as a CA (somebody that is trusted by some group of users for the purpose of validating applicants and issuing certs to them) and what the protocol sees as a CA -- always an issuing privatekey and one or more matching certs; usually some combination of CRL distribution points and/or OCSP responders; often some online-published policy(ies); and sometimes name or policy constraints in the cert(s). (Even if not in the cert there are practically always policies and constraints in the real world.) Most real CA organizations actually consist of several techincal CAs: usually one root CA with 2 or 3 or 10 subordinate CAs. On a given handshake the server can send only one server cert, which is signed by exactly one issuing/parent CA (or is self-signed in which case effectively it is its own CA). But if that issuing CA is not a root, and for public/wellknown CAs it never is, it can obtain and publish chain certs signed by several different roots and/or higher-level CAs, especially for old and new generations or mergers etc. Then there exist multiple trust chains leading to (or from?) different roots/anchors, and different validators may use different chains depending on which roots/anchors each trusts and which intermediates it has or gets. > on the other side, a client have (in general) a list of trusted CAs, not a > single > one > yes. Usually (but not mandatorily) in the form of a list of trusted CA certs. > so there are two options : > - either each client knows the two CAs, then the server can send a certificate > signed by any of them > - or each client knows only about its own CA, then the server must send a > certificate signed by both CAs > (note that this is symmetrical, the server verify client certificate the same > way) > when client auth aka client cert is used, which is rare and apparently not the case here, although the OPs posts have been rather unclear. > I've never heard about a server with multiple certificates, at least not with > SSL/TLS protocols... > It can and must when supporting certain different key-exchange methods. In particular a cert for an RSA key can support plain-RSA and [EC]DHE-RSA key-exchange, but only a DSA cert can support DHE-DSS and only an ECC cert (perhaps restricted to signature) can support ECDHE-ECDSA. (There are also rules for static-[EC]DH but practically nobody uses those.) These certs usually (should) have the same subject name, but must have different subject keys and may well be issued by different CAs. In addition, a single physical server can implement multiple "virtual" or "logical" servers by responding on multiple IP addresses and/or ports (the old way which always works) or using ServerNameIndication in the ClientHello (requires client support, but now pretty widespread). These logical servers can have different certs, and often must because they usually are seen by the users/clients at different domain names (which map or forward to the one physical server) and the cert used must match the requested domain name -- although one cert *can* use wildcards or SubjectAlternativeNames to match multiple names. > > concerning the list of trusted CAs sent by the server to the client, it comes > from the fact that a client can have multiple certificates, for different > servers > that can use their own CA > so it allows a client to choose the good certificate to send to a specific > server > Usually yes, although some clients notably including openssl commandline s_client are dumb and select client cert ignoring server's CertReq. > concerning the server, if it's in public access it uses a certificate issued > by a > "well-known" CA (for example one included in your browser) > if it's "private", it can use its own CA or even a self-signed certificate, > and the > client has to recover the trusted certificates by itself (this happens the > first > time you connect to a SSH server for which you have no certificate, or on > some websites) > A more-or-less private server *can* use a private CA -- possibly its own, possibly private but separate e.g. the corporate security department might run one CA that certifies machines at all 100 branch offices. But a private server can get a public CA cert as long as you use domain(s) you control, and using that may be more convenient. (I don't think this disagrees with what you said, just spells it out explicitly.) SSH doesn't use certificates at all; client learns the server *publickey* on first connection (which *should* be manually checked, but probably .0001% of users actually do) and remembers it thereafter. For SSH client auth there are several options only one of which uses publickey, and for that option the publickey must be explicitly transferred to and configured on server. (A user can connect the first time using e.g. password, use that connection to configure pubkey, and subsequently use publickey.) > > hope I made it clear > good luck! > > > ----- Mail d'origine ----- > De: Hafedh TRIMECHE <hafedh.trime...@gmail.com> > À: openssl-users@openssl.org > Envoyé: Fri, 13 Jun 2014 10:22:46 +0200 (CEST) > Objet: Re: Re : Re: Re : Re: 2 Server certificates > > Hi Nicolas, > > pit-ca issued another certificate to a client wanting to connect to the same > server identified by secure.payerspot.com. > > I'm looking for a solution allowing two clients to connect to the same > server using certificates issued by different CAs. > > In this case the client forces the server verification by requesting its > certificate. > > So the two server certificates must be sent to each client . > > Cetificate chain1 (issued by CA1) > 0 s: > i: > ----BEGIN CERTIFICATE----- > -----END CERTIFICATE----- > > Cetificate chain2 (issued by CA2) > 0 s: > i: > ----BEGIN CERTIFICATE----- > -----END CERTIFICATE----- > > Can two certificates be presented to a client which will identify the > chained certificate to be verified ? > > Regards. > > > > > -- > View this message in context: http://openssl.6102.n7.nabble.com/2-Server- > certificates-tp50872p50937.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > __________________________________________________________ > ____________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > > __________________________________________________________ > ____________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
