Résolution des problèmes liés aux certificats SSL certificate-problems

Certificat non valide invalid-certificate

Cette erreur se produit, car le client a utilisé une clé privée chiffrée et a fourni la clé au format DER.

La clé privée doit être au format PKCS 8. pkcs-8

Cette erreur se produit, car le client a utilisé une clé privée chiffrée et a fourni la clé au format DER.

Ordre de certificat correct certificate-order

La raison la plus courante de l’échec du déploiement d’un certificat est que les certificats intermédiaires ou de chaîne ne sont pas dans le bon ordre.

Les fichiers de certificat intermédiaires doivent se terminer par le certificat racine ou le certificat le plus proche de la racine. Ils doivent être dans l’ordre descendant du certificat main/server à la racine.

Vous pouvez déterminer l’ordre de vos fichiers intermédiaires à l’aide de la commande suivante.

openssl crl2pkcs7 -nocrl -certfile $CERT_FILE | openssl pkcs7 -print_certs -noout

Vous pouvez vérifier que la clé privée et le certificat main/server correspondent à l’aide des commandes suivantes.

openssl x509 -noout -modulus -in certificate.pem | openssl md5

openssl rsa -noout -modulus -in ssl.key | openssl md5

Supprimer les certificats clients client-certificates

Lors de l’ajout d’un certificat, si vous recevez une erreur similaire à ce qui suit :

The Subject of an intermediate certificate must match the issuer in the previous certificate. The SKI of an intermediate certificate must match the AKI of the previous certificate.

Vous avez probablement inclus le certificat client dans la chaîne de certificats. Assurez-vous que la chaîne n’inclut pas le certificat client, puis réessayez.

Politique de certificat policy

Si l’erreur suivante s’affiche, veuillez vérifier la politique de votre certificat.

Certificate policy must conform with EV or OV, and not DV policy.

Les valeurs OID intégrées identifient normalement les politiques de certificat. La génération d’un certificat dans du texte et la recherche de l’OID révèlent la politique du certificat.

Vous pouvez générer les détails de votre certificat sous forme de texte à l’aide de l’exemple suivant comme guide.

openssl x509 -in 9178c0f58cb8fccc.pem -text
certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            91:78:c0:f5:8c:b8:fc:cc
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
        Validity
            Not Before: Nov 10 22:55:36 2021 GMT
            Not After : Dec  6 15:35:06 2022 GMT
        Subject: C = US, ST = Colorado, L = Denver, O = Alexandra Alwin, CN = adobedigitalimpact.com
        Subject Public Key Info:
...

Le modèle OID dans le texte définit le type de politique du certificat.

À l’aide de grep ping pour les modèles OID dans le texte du certificat de sortie, vous pouvez confirmer votre politique de certificat.

# "EV Policy"
openssl x509 -in certificate.pem -text grep "Policy: 2.23.140.1.1" -B5

# "OV Policy"
openssl x509 -in certificate.pem -text grep "Policy: 2.23.140.1.2.2" -B5

# "DV Policy - Not Accepted"
openssl x509 -in certificate.pem -text grep "Policy: 2.23.140.1.2.1" -B5

Validité du certificat validity

Cloud Manager s’attend à ce que le certificat SSL soit valide pendant au moins 90 jours à compter de la date actuelle. Vérifiez la validité de la chaîne de certificats.

Un certificat SAN incorrect est appliqué à mon domaine wrong-san-cert

Supposons que vous souhaitiez lier dev.yoursite.com et stage.yoursite.com à votre environnement hors production et prod.yoursite.com à votre environnement de production.

Pour configurer le réseau CDN pour ces domaines, vous avez besoin d’un certificat installé pour chacun d’eux. Vous installez donc un certificat qui couvre les *.yoursite.com pour vos domaines hors production et un autre qui couvre également les *.yoursite.com pour vos domaines de production.

Cette configuration est valide. Cependant, lorsque vous mettez à jour l’un des certificats, car les deux certificats couvrent la même entrée SAN, le réseau CDN installe le certificat le plus récent sur tous les domaines applicables, ce qui peut sembler inattendu.

Bien que cela puisse être inattendu, il ne s’agit pas d’une erreur et il s’agit du comportement standard du réseau CDN sous-jacent. Si vous disposez de plusieurs certificats SAN couvrant la même entrée de domaine SAN, si ce domaine est couvert par un certificat et que l’autre est mis à jour, ce dernier est désormais installé pour le domaine.