Résoudre les problèmes liés aux certificats SSL

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Les procédures de dépannage dépendent du type de certificats SSL utilisés.

Résoudre les problèmes liés aux certificats gérés par Google

Il existe deux types d'état pour les certificats gérés par Google :

• État géré
• État du domaine

État géré

Pour vérifier l'état du certificat, exécutez la commande suivante :

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
    --global \
    --format="get(name,managed.status)"

Les valeurs de l'état géré sont les suivantes :

État du domaine

Pour vérifier l'état du domaine, exécutez la commande suivante :

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
    --global \
    --format="get(managed.domainStatus)"

Ce tableau répertorie les valeurs de l'état du domaine.

Renouvellement des certificats gérés

Pour vous assurer que vos certificats ne échouent pas à l'étape de validation du domaine du processus de renouvellement, consultez les exigences concernant vos enregistrements DNS A et AAAA.

Validation multiperspective du domaine

Google Cloud renouvelle régulièrement vos certificats gérés par Google en les demandant aux autorités de certification (autorités CA). Les autorités de certification avec lesquellesGoogle Cloud fonctionne pour renouveler vos certificats utilisent une méthode de validation de domaine multiperspective appelée Multi-Perspective Issuance Corroboration (MPIC). Dans le cadre de ce processus, les autorités de certification vérifient le contrôle du domaine en vérifiant les paramètres DNS du domaine et en essayant de contacter le serveur derrière l'adresse IP du domaine. Ces vérifications sont effectuées à partir de plusieurs points de vue sur Internet. Si le processus de validation échoue, le renouvellement des certificats gérés par Google échoue. Par conséquent, votre équilibreur de charge fournit un certificat expiré aux clients, ce qui entraîne des erreurs de certificat pour les utilisateurs de navigateurs et des échecs de connexion pour les clients d'API.

Pour éviter les échecs de validation de domaine multiperspective pour les enregistrements DNS mal configurés, notez les points suivants:

• Vos enregistrements DNS A (IPv4) et DNS AAAA (IPv6) pour vos domaines et tous vos sous-domaines pointent uniquement vers l'adresse IP (ou les adresses IP) associée à la ou aux règles de transfert de l'équilibreur de charge. L'existence d'autres adresses dans l'enregistrement peut entraîner l'échec de la validation.
• L'autorité de certification, qui valide les enregistrements DNS, interroge les enregistrements DNS à partir de plusieurs emplacements. Assurez-vous que votre fournisseur DNS répond de manière cohérente à toutes les requêtes de validation de domaine global.
• L'utilisation de GeoDNS (qui renvoie différentes adresses IP en fonction de l'emplacement de la requête) ou de règles DNS basées sur la localisation peut entraîner des réponses incohérentes et l'échec de la validation. Si votre fournisseur DNS utilise GeoDNS, désactivez-le ou assurez-vous que toutes les régions renvoient l'adresse IP du même équilibreur de charge.
• Vous devez spécifier explicitement les adresses IP de votre équilibreur de charge dans votre configuration DNS. Les couches intermédiaires, telles qu'un CDN, peuvent entraîner un comportement imprévisible. L'adresse IP doit être directement accessible sans redirection, pare-feu ni CDN dans le chemin de la requête. Pour en savoir plus, consultez la section Équilibreurs de charge derrière un CDN de ce document.
• Nous vous recommandons d'utiliser un outil de vérification de la propagation DNS mondial de votre choix pour vérifier que tous les enregistrements DNS pertinents sont correctement résolus et cohérents dans le monde entier.

Vérifier les modifications de configuration

Une fois que vous avez configuré vos enregistrements DNS, vous pouvez vérifier qu'ils sont corrects en créant un certificat et en le connectant à votre équilibreur de charge avec le certificat existant. Cette étape force une vérification immédiate du provisionnement de certificat auprès de l'autorité de certification, ce qui vous permet de vérifier les modifications de votre configuration en quelques minutes. Sans cela, le renouvellement automatique du certificat existant peut prendre des jours ou des semaines, ce qui laisse planer le doute sur votre configuration.

Si l'état du certificat devient ACTIVE, cela signifie que le certificat a été émis, ce qui confirme que votre configuration DNS est correcte. À ce stade, nous vous recommandons de supprimer le certificat précédent pour éviter d'avoir deux certificats distincts pour le même domaine. Ce processus n'interrompt pas le trafic vers votre équilibreur de charge.

Le nouveau certificat sert d'outil de validation. Sa création confirme que la validation multiperspective du domaine à l'aide de MPIC fonctionne correctement pour votre configuration.

Équilibreurs de charge derrière un CDN

Pour les équilibreurs de charge sur lesquels le CDN est activé, certains fournisseurs CDN tiers dans le chemin de requête peuvent empêcher la réussite des requêtes de validation. Cela peut se produire si le fournisseur CDN transmet activement le trafic HTTP(S) au proxy.

Dans ce cas, nous vous recommandons de migrer vos certificats vers le Gestionnaire de certificats et d'utiliser la méthode d'autorisation DNS pour provisionner des certificats gérés par Google. Cette dernière approche ne nécessite pas que l'autorité de certification contacte votre équilibreur de charge.

Résoudre les problèmes liés aux certificats SSL autogérés

Ce guide explique comment résoudre les problèmes de configuration des certificats SSL autogérés.

Impossible d'analyser le certificat

Google Cloud nécessite des certificats au format PEM. Si le certificat est au format PEM, vérifiez les éléments suivants :

Vous pouvez valider votre certificat à l'aide de la commande OpenSSL suivante, en remplaçant CERTIFICATE_FILE par le chemin d'accès au fichier de certificat :

openssl x509 -in CERTIFICATE_FILE -text -noout

Si OpenSSL ne parvient pas à analyser votre certificat, procédez comme suit :

• Contactez votre autorité de certification pour obtenir de l'aide.
• Créez une clé privée et un certificat.

Nom courant ou autre nom d'objet manquant

Google Cloud requiert que votre certificat ait un nom courant (CN) ou un autre nom d'objet (SAN). Pour en savoir plus, consultez la section Créer une requête de signature de certificat.

En l'absence des deux attributs, Google Cloud affiche un message d'erreur du type suivant lorsque vous essayez de créer un certificat autogéré:

ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch resource:
 -   The SSL certificate is missing a Common Name(CN) or Subject Alternative
   Name(SAN).

Impossible d'analyser la clé privée

Google Cloud nécessite l'utilisation de clés privées au format PEM respectant les critères de clé privée.

Vous pouvez valider votre clé privée à l'aide de la commande OpenSSL suivante, en remplaçant PRIVATE_KEY_FILE par le chemin d'accès à la clé privée :

    openssl rsa -in PRIVATE_KEY_FILE -check

Les réponses suivantes indiquent un problème avec la clé privée :

• unable to load Private Key
• Expecting: ANY PRIVATE KEY
• RSA key error: n does not equal p q
• RSA key error: d e not congruent to 1
• RSA key error: dmp1 not congruent to d
• RSA key error: dmq1 not congruent to d
• RSA key error: iqmp not inverse of q

Pour résoudre le problème, vous devez créer une clé privée et un certificat.

Clés privées avec phrases secrètes

Si OpenSSL vous invite à saisir une phrase secrète, vous devez supprimer celle de votre clé privée avant de pouvoir l'utiliser avec Google Cloud. Vous pouvez exécuter la commande OpenSSL suivante :

openssl rsa -in PRIVATE_KEY_FILE \
    -out REPLACEMENT_PRIVATE_KEY_FILE

Remplacez les espaces réservés par des valeurs valides :

• PRIVATE_KEY_FILE : chemin d'accès à la clé privée protégée par une phrase secrète
• REPLACEMENT_PRIVATE_KEY_FILE : chemin d'accès où vous souhaitez enregistrer une copie de votre clé privée en texte brut

Expiration des certificats intermédiaires

Si un certificat intermédiaire expire avant le certificat du serveur (feuille), cela peut indiquer que votre autorité de certification ne suit pas les bonnes pratiques.

Lorsqu'un certificat intermédiaire expire, le certificat du serveur utilisé dansGoogle Cloud peut devenir non valide. Cela dépend du client SSL, comme suit :

• Certains clients SSL ne vérifient que le délai d'expiration du certificat du serveur et ignorent les certificats intermédiaires expirés.
• Certains clients SSL traitent une chaîne avec un ou plusieurs certificats intermédiaires arrivés à expiration comme non valide et affichent un avertissement.

Pour remédier à ce problème :

1. Attendez que l'autorité de certification bascule vers un nouveau certificat intermédiaire.
2. Demandez un nouveau certificat à l'autorité de certification.
3. Importez à nouveau le nouveau certificat avec les nouvelles clés.

L'autorité de certification peut également autoriser la signature croisée pour les certificats intermédiaires. Renseignez-vous auprès de votre autorité de certification.

L'exposant public RSA est trop grand

Le message d'erreur suivant s'affiche lorsque l'exposant public RSA est supérieur à 65537. Assurez-vous d'utiliser 65537, comme spécifié dans le document RFC 4871.

ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch resource:
 -   The RSA public exponent is too large.

Supprimer le certificat SSL du proxy cible

Les étapes suivantes montrent comment supprimer un seul certificat SSL associé au proxy HTTPS cible :

1. Exportez le proxy https cible vers un fichier temporaire.

   gcloud compute target-https-proxies export TARGET_PROXY_NAME > /tmp/proxy
   

2. Modifiez le fichier /tmp/proxy et supprimez les lignes suivantes :

   sslCertificates:
   -   https://www.googleapis.com/compute/v1/projects/...
   

3. Importez le fichier /tmp/proxy.

   gcloud compute target-https-proxies import TARGET_PROXY_NAME \
      --source=/tmp/proxy
   

4. (Facultatif) Supprimez le certificat SSL.

   gcloud compute ssl-certificates delete SSL_CERT_NAME
   

Remplacez les éléments suivants :

• TARGET_PROXY_NAME : nom de la ressource proxy HTTPS cible.
• SSL_CERT_NAME : nom du certificat SSL.