Télécharger une chaîne via PLESK où il n'y a que des champs pour le certificat et l'autorité?
J'ai un paquet de certificats gratuit qui comprend des fichiers racine, intermédiaire, serveur et CA crt. J'essaie d'utiliser ce certificat tiers dans une solution hébergée GoDaddy PLESK et j'ai la possibilité de télécharger les certificats sous forme de texte dans deux champs: certificat et champ de texte CA de certificat. Jusqu'à présent, j'ai téléchargé le certificat de serveur et le certificat CA, mais une vérification SSL confirme que la chaîne est incomplète et certains utilisateurs rencontrent une erreur de certificat dans Chrome.
Comment puis-je télécharger la chaîne entière dans ces deux champs? Je comprends que je peux copier la valeur de texte des fichiers crt les uns après les autres dans un seul champ. Quelle valeur de certificat va dans quel champ dans quel ordre?
Vous devez concaténer tous les certificats (c'est-à-dire intermédiaires - mais vous pouvez en avoir un ou plusieurs - et CA) et les placer dans le champ "certificat CA", pendant que vous placez le certificat de serveur dans le champ "certificat".
Notez que le certificat CA (certificat "racine") n'est techniquement pas nécessaire dans le champ "certificat CA" (qui introduit alors un terme assez trompeur) parce que les clients devraient déjà avoir localement le certificat CA (racine), donc seulement les intermédiaires devrait être nécessaire. Mais l'ajout de la racine ne devrait pas non plus avoir d'inconvénients.
La commande n'est normalement pas pertinente.
Les dernières spécifications TLS ( https://tools.ietf.org/html/rfc8446#section-4.4.2 ) disent ceci:
Étant donné que la validation de certificat nécessite que les ancres de confiance soient distribuées indépendamment, un certificat qui spécifie une ancre de confiance PEUT être omis de la chaîne, à condition que les homologues pris en charge soient connus pour posséder des certificats omis.
et
Remarque: Avant TLS 1.3, la commande "certificate_list" exigeait chacun
certificat pour certifier celui qui le précède immédiatement; cependant,
certaines implémentations ont permis une certaine flexibilité. Serveurs parfois
envoyer à la fois un intermédiaire actuel et obsolète pour transition
, et d'autres sont simplement mal configurés, mais ceux-ci
les cas peuvent néanmoins être validés correctement. Pour maximum
compatibilité, toutes les implémentations DEVRAIENT être préparées à gérer
certificats potentiellement superflus et commandes arbitraires de tout
Version TLS, à l'exception du certificat d'entité finale qui
DOIT être le premier.
(vous n'avez pas à vous soucier de la dernière partie, car cela se fait automatiquement correctement par le logiciel serveur car vous avez deux champs, pour séparer clairement le certificat du serveur des "autres".)
De cette façon, le serveur doit envoyer correctement d'un côté son certificat, et séparément la chaîne de confiance requise par les clients pour vérifier que votre certificat de serveur est valide et descend d'une autorité de certification connue à laquelle ils font confiance.