Réparateur de chaîne de certificats — ordonner et compléter un paquet SSL

Parce que le certificat intermédiaire manque dans ce que votre serveur envoie. Les navigateurs de bureau masquent cela : ils mettent en cache les intermédiaires vus sur d'autres sites et peuvent télécharger celui qui manque depuis l'adresse figurant dans le certificat. Android, curl, Java, Python et la plupart des clients d'API ne font ni l'un ni l'autre : ils voient une chaîne qui n'atteint jamais de racine de confiance et refusent la connexion. Collez ici votre chaîne : si un intermédiaire est signalé manquant, c'est tout le bogue.

D'abord le certificat serveur, puis l'intermédiaire qui l'a émis, puis l'émetteur de celui-ci, et ainsi de suite. La racine est omise. Certains serveurs tolèrent un autre ordre, mais OpenSSL, Java et la plupart des répartiteurs de charge non : la réponse sûre est donc toujours « le certificat final en premier ».

Non. Un client fait confiance à une racine parce qu'elle est dans son propre magasin, pas parce qu'un serveur la lui a envoyée : une racine transmise sur le réseau est ignorée et n'ajoute qu'un ou deux kilo-octets à chaque poignée de main. C'est inoffensif mais inutile, et le fichier produit par cet outil l'exclut.

Auprès de l'autorité de certification, sur la page même où vous avez récupéré votre certificat. Les utilisateurs de Let's Encrypt n'y sont normalement pas confrontés, car certbot écrit fullchain.pem avec l'intermédiaire déjà inclus : si vous avez configuré cert.pem au lieu de fullchain.pem, changer le chemin suffit.

Un certificat présent dans votre fichier qui n'y a rien émis et n'y a été émis par rien. C'est en général un reste d'un certificat précédent, ou une racine collée à côté d'une chaîne qui aboutit à une autre racine. Il ne casse rien en soi, mais il indique un fichier assemblé à la main : cela vaut un nettoyage.