Le serveur peut-il envoyer plusieurs certificats au client?

Question

J'ai écrit une petite application client et serveur Java 7. J'ai keystore avec 3 certificats X.509 RSA auto-signés. Lorsque le client se connecte via SSL, le serveur envoie un message de certificat SSL avec un seul certificat. Je suis un peu nouveau sur SSL/TLS. J'ai aussi regardé le code JSSE sun.security.ssl.X509KeyManagerImpl et trouvé ci-dessous les commentaires:

/* 
* Return the best alias that fits the given parameters. 
* The algorithm we use is: 
* . scan through all the aliases in all builders in order 
* . as soon as we find a perfect match, return 
*  (i.e. a match with a cert that has appropriate key usage 
*  and is not expired). 
* . if we do not find a perfect match, keep looping and remember 
*  the imperfect matches 
* . at the end, sort the imperfect matches. we prefer expired certs 
*  with appropriate key usage to certs with the wrong key usage. 
*  return the first one of them. 
*/ 
private String More ...chooseAlias(List<KeyType> keyTypeList, 
     Principal[] issuers, CheckType checkType) 

Commentaire est assez clair que le serveur envoie unique meilleur certificat correspondant, mais je ne semble pas comprendre la raison. Comme dans mon cas, je veux que le serveur envoie tous les 3 certificats, afin que le client puisse en choisir un et valider la chaîne. Et aussi, si mon client n'a pas le certificat que le serveur envoie, la connexion est abandonnée avec SSLHandshakeException 'Aucun certificat de confiance trouvé'. Donc ma question est la suivante: pourquoi le serveur ne peut-il pas envoyer les 3 certificats si le client a demandé des informations (de ClientHello) avec les 3 certificats? Est-ce quelque chose à voir avec TLS 1.0 vs TLS 1.2?

Answer 1

Le protocole de prise de contact TLS permet uniquement la transmission d'un certificat d'entité finale client (c'est également le cas pour les certificats de serveur). Les certificats intermédiaires peuvent être transmis, mais ce que vous semblez vouloir - la transmission de plusieurs certificats d'entité finale - n'est pas possible.

La structure du TLS serveur/certificat client message est défini dans RFC 5246 (TLS 1.2) section 7.4.2:

Structure of this message: 

     opaque ASN.1Cert<1..2^24-1>; 

     struct { 
      ASN.1Cert certificate_list<0..2^24-1>; 
     } Certificate; 

    certificate_list 
     This is a sequence (chain) of certificates. The sender's 
     certificate MUST come first in the list. Each following 
     certificate MUST directly certify the one preceding it. Because 
     certificate validation requires that root keys be distributed 
     independently, the self-signed certificate that specifies the root 
     certificate authority MAY be omitted from the chain, under the 
     assumption that the remote end must already possess it in order to 
     validate it in any case. 

En ce qui concerne le certificat que le client choisit de présenter, si vous configurez votre serveur pour annoncer son CA de confiance pour la validation du certificat client (le champ certificate_authorities du message CertificateRequest, voir ci-dessous), puis le code côté client qui sélectionne le certificat à présenter doit sélectionner un certificat qui est certifié par l'une des autorités de certification annoncées.

7.4.4. Certificate Request 

    ... 

    Structure of this message: 

     enum { 
      rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 
      rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), 
      fortezza_dms_RESERVED(20), (255) 
     } ClientCertificateType; 

     opaque DistinguishedName<1..2^16-1>; 

     struct { 
      ClientCertificateType certificate_types<1..2^8-1>; 
      SignatureAndHashAlgorithm 
      supported_signature_algorithms<2^16-1>; 
      DistinguishedName certificate_authorities<0..2^16-1>; 
     } CertificateRequest; 

    ... 

    certificate_authorities 
     A list of the distinguished names [X501] of acceptable 
     certificate_authorities, represented in DER-encoded format. These 
     distinguished names may specify a desired distinguished name for a 
     root CA or for a subordinate CA; thus, this message can be used to 
     describe known roots as well as a desired authorization space. If 
     the certificate_authorities list is empty, then the client MAY 
     send any certificate of the appropriate ClientCertificateType, 
     unless there is some external arrangement to the contrary. 

Et, de la section 7.4.6:

If the certificate_authorities list in the certificate request 
    message was non-empty, one of the certificates in the certificate 
    chain SHOULD be issued by one of the listed CAs. 

Answer 2

Malchance, vous ne pouvez en envoyer qu'une seule. Voir RFC 2616 & ff.