Créer une autorité de certification secondaire

Cette page décrit la procédure à suivre pour créer une autorité de certification subordonnée (AC subordonnée).

Les sous-autorités de certification sont chargées d'émettre des certificats directement aux entités finales, telles que les utilisateurs, les ordinateurs et les appareils. Ils sont signés de manière cryptographique par une AC parente, souvent l'AC racine. Les systèmes qui font confiance à l'autorité de certification racine font automatiquement confiance aux autorités de certification subordonnées et aux certificats qu'elles émettent.

Le signataire du certificat CA peut être une autre autorité de certification créée dans CA Service (une autorité de certification racine, par exemple) ou une autorité de certification externe. Avec les CA externes, CA Service génère une demande de signature de certificat (CSR) que la CA externe doit signer.

Avant de commencer

Pour obtenir les autorisations nécessaires pour créer une autorité de certification subordonnée, demandez à l'administrateur IAM de votre organisation de vous accorder le rôle Administrateur du service d'autorité de certification (certificate-authority-service-admin). Pour en savoir plus sur les rôles, consultez Définitions des rôles.

Obtenir le fichier kubeconfig

Pour exécuter des commandes sur le serveur de l'API Management, assurez-vous de disposer des ressources suivantes :

• Connectez-vous et générez le fichier kubeconfig pour le serveur d'API Management si vous n'en avez pas.

• Utilisez le chemin d'accès au fichier kubeconfig du serveur de l'API Management pour remplacer MANAGEMENT_API_SERVER_KUBECONFIG dans ces instructions.

Créer une sous-autorité de certification gérée

Pour une CA subordonnée gérée, le signataire du certificat CA est une autre CA (CA racine) créée dans CA Service.

Pour créer une sous-autorité de certification gérée, appliquez une ressource personnalisée à votre instance Distributed Cloud Appliance.

1. Créez une ressource CertificateAuthority et enregistrez-la en tant que fichier YAML nommé subca.yaml :

   apiVersion: pki.security.gdc.goog/v1
   kind: CertificateAuthority
   metadata:
     Name: SUB_CA_NAME
     namespace: USER_PROJECT_NAMESPACE
   spec:
     caProfile:
       commonName: COMMON_NAME
       duration: DURATION
       renewBefore: RENEW_BEFORE
       organizations:
       - ORGANIZATIONS
       organizationalUnits:
       - ORGANIZATIONAL_UNITS
       countries:
       - COUNTRIES
       localities:
       - LOCALITIES
       provinces:
       - PROVINCES
       streetAddresses:
       - STREET_ADDRESSES
       postalCodes:
       - POSTAL_CODES
     caCertificate:
       managedSubCA:
         certificateAuthorityRef:
           name: ROOT_CA_NAME
           namespace: USER_PROJECT_NAMESPACE
     certificateProfile:
       keyUsage:
         - digitalSignature
         - keyCertSign
         - crlSign
       extendedKeyUsage:
         - EXTENDED_KEY_USAGE
     secretConfig:
       secretName: SECRET_NAME
       privateKeyConfig:
         algorithm: KEY_ALGORITHM
         size: KEY_SIZE
     acme:
       enabled: ACME_ENABLED
   

   Remplacez les variables suivantes :

   Variable	Description
   SUB_CA_NAME	Nom de l'autorité de certification subordonnée.
   USER_PROJECT_NAMESPACE	Nom de l'espace de noms dans lequel réside le projet utilisateur.
   COMMON_NAME	Nom commun du certificat de l'autorité de certification.
   DURATION	Durée de vie demandée du certificat CA.
   ROOT_CA_NAME	Nom de l'autorité de certification racine.
   SECRET_NAME	Nom du secret Kubernetes contenant la clé privée et le certificat CA signé.

   Les variables suivantes sont des valeurs facultatives :

   Variable	Description
   RENEW_BEFORE	Délai de rotation avant l'expiration du certificat CA.
   ORGANIZATIONS	Organisations à utiliser sur le certificat.
   ORGANIZATIONAL_UNITS	Unités organisationnelles à utiliser sur le certificat.
   COUNTRIES	Pays à utiliser sur le certificat.
   LOCALITIES	Villes à utiliser sur le certificat.
   PROVINCES	États ou provinces à utiliser sur le certificat.
   STREET_ADDRESSES	Adresses postales à utiliser sur le certificat.
   POSTAL_CODES	Codes postaux à utiliser sur le certificat.
   EXTENDED_KEY_USAGE	Utilisation étendue de la clé pour le certificat. Si elle est fournie, les valeurs autorisées sont serverAuth et clientAuth.
   KEY_ALGORITHYM	Algorithme de clé privée utilisé pour ce certificat. Les valeurs autorisées sont RSA, Ed25519 ou ECDSA. Si la taille n'est pas indiquée, la valeur par défaut est 256 pour ECDSA et 2048 pour RSA. La taille de la clé est ignorée pour Ed25519.
   KEY_SIZE	La taille, en bits, de la clé privée de ce certificat dépend de l'algorithme. RSA autorise 2 048, 3 072, 4 096 ou 8 192 (2 048 par défaut). ECDSA : autorise 256, 384 ou 521 (256 par défaut). Ed25519 ignore la taille.
   ACME_ENABLED	Si la valeur est définie sur true, l'autorité de certification s'exécute en mode ACME et génère l'URL du serveur ACME. Vous pouvez ensuite utiliser le client et le protocole ACME pour gérer les certificats.

2. Appliquez la ressource personnalisée à votre instance Distributed Cloud :

   kubectl apply -f subca.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
   

   Remplacez MANAGEMENT_API_SERVER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du serveur de l'API Management.

3. Vérifiez que la sous-autorité de certification est prête. Il faut environ 40 minutes pour que l'autorité de certification soit prête :

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' 
   .status.conditions[] | select( .type as $id | "Ready" | index($id))'
   

   La sortie ressemble à ceci :

   {
     "lastTransitionTime": "2025-01-24T17:09:29Z",
     "message": "CA reconciled",
     "observedGeneration": 2,
     "reason": "Ready",
     "status": "True",
     "type": "Ready"
   }
   

Créer une sous-autorité de certification à partir d'une autorité de certification externe

Cette sous-autorité de certification permet de signer des certificats feuille avec des autorités de certification externes ou gérées par l'utilisateur. Il génère une RDC que les utilisateurs doivent signer.

1. Créez une ressource CertificateAuthority et enregistrez-la en tant que fichier YAML nommé subca-external.yaml :

   apiVersion: pki.security.gdc.goog/v1
   kind: CertificateAuthority
   metadata:
     Name: SUB_CA_NAME
     namespace: USER_PROJECT_NAMESPACE
   spec:
     caProfile:
       commonName: COMMON_NAME
       duration: DURATION
       renewBefore: RENEW_BEFORE
       organizations:
       - ORGANIZATION
       organizationalUnits:
       - ORGANIZATIONAL_UNITS
       countries:
       - COUNTRIES
       localities:
       - LOCALITIES
       provinces:
       - PROVINCES
       streetAddresses:
       - STREET_ADDRESSES
       postalCodes:
       - POSTAL_CODES
     caCertificate:
       externalCA: {}
     certificateProfile:
       keyUsage:
         - digitalSignature
         - keyCertSign
         - crlSign
       extendedKeyUsage:
         - EXTENDED_KEY_USAGE
     secretConfig:
       secretName: SECRET_NAME
       privateKeyConfig:
         algorithm: KEY_ALGORITHM
         size: KEY_SIZE
     acme:
       enabled: ACME_ENABLED
   

   Remplacez les variables suivantes :

   Variable	Description
   SUB_CA_NAME	Nom de la sous-autorité de certification.
   USER_PROJECT_NAMESPACE	ID du projet dans lequel vous souhaitez importer l'image.
   COMMON_NAME	Nom commun du certificat de l'autorité de certification.
   DURATION	Durée de vie demandée du certificat CA
   SECRET_NAME	Nom du secret Kubernetes contenant la clé privée et le certificat CA signé.

   Les variables suivantes sont des valeurs facultatives :

   Variable	Description
   RENEW_BEFORE	Délai de rotation avant l'expiration du certificat CA.
   ORGANIZATION	Organisation à utiliser sur le certificat.
   ORGANIZATIONAL_UNITS	Unités organisationnelles à utiliser sur le certificat.
   COUNTRIES	Pays à utiliser sur le certificat.
   LOCALITIES	Villes à utiliser sur le certificat.
   PROVINCES	États ou provinces à utiliser sur le certificat.
   STREET_ADDRESSES	Adresses postales à utiliser sur le certificat.
   POSTAL_CODES	Codes postaux à utiliser sur le certificat.
   EXTENDED_KEY_USAGE	Utilisation étendue de la clé pour le certificat. Si elle est fournie, les valeurs autorisées sont serverAuth et clientAuth.
   KEY_ALGORITHYM	Algorithme de clé privée utilisé pour ce certificat. Les valeurs autorisées sont RSA, Ed25519 ou ECDSA. Si la taille n'est pas indiquée, la valeur par défaut est 256 pour ECDSA et 2 048 pour RSA. La taille de la clé est ignorée pour Ed25519.
   KEY_SIZE	La taille, en bits, de la clé privée de ce certificat dépend de l'algorithme. RSA autorise les valeurs 2048, 3072, 4096 ou 8192 (2048 par défaut). ECDSA autorise 256, 384 ou 521 (256 par défaut). Ed25519 ignore la taille.
   ACME_ENABLED	Si la valeur est définie sur true, l'autorité de certification s'exécute en mode ACME et génère l'URL du serveur ACME. Vous pouvez ensuite utiliser le client et le protocole ACME pour gérer les certificats.

2. Appliquez la ressource personnalisée à votre instance Distributed Cloud :

   kubectl apply -f subca-external.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
   

3. Une RDC pour la sous-autorité de certification est générée sur le serveur de l'API GDC Management. Vous devez télécharger la CSR et la signer. Une fois signé, vous pouvez importer le certificat signé sur le serveur de l'API GDC Management.

4. Rassemblez les demandes de signature de certificat (CSR) de votre environnement Distributed Cloud :

   kubectl get certificateauthorities SUB_CA_NAME -n USER_PROJECT_NAMESPACE -ojson | jq -j '"echo ", .status.externalCA.csr, " | base64 -d > ","sub_ca.csr\n"' | bash
   

   La commande génère un fichier CSR nommé sub_ca.csr dans le répertoire actuel. Ce fichier contient une CSR pour un certificat d'AC X.509.

5. Utilisez l'autorité de certification racine du client pour demander des certificats d'autorité de certification signés pour le fichier sub_ca.csr.

6. Pour une demande de signature de certificat approuvée, vous devez obtenir un certificat d'autorité de certification signé par l'autorité de certification racine du client. Stockez le certificat dans le fichier sub_ca.crt du répertoire actuel.

7. Le cas échéant, obtenez le certificat CA racine du client et stockez-le dans le fichier ca.crt du répertoire actuel.

8. Vérifiez les extensions SAN (Subject Alternative Name) dans le certificat :

   openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject Alternative Name"
   

   Si le certificat d'autorité de certification comporte un nom commun (CN) plutôt qu'un SAN, vérifiez le CN dans le certificat :

   openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject: CN"
   

9. Générez le spec pour corriger la ressource CertificateAuthority :

   echo "spec:
     caCertificate:
       externalCA:
         signedCertificate:
           certificate: $(base64 -w0 SUB_CA_NAME.crt)
           ca: $(base64 -w0 ca.crt)" > patch.txt
   

   Le contenu du fichier patch.txt ressemble à ce qui suit :

   spec:
     caCertificate:
       externalCA:
         signedCertificate:
           certificate: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURSekNDQ…
           ca: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURRVENDQ…
   

10. Modifiez le champ spec de la ressource CertificateAuthority :

    kubectl patch certificateauthority SUB_CA_NAME -n USER_PROJECT_NAMESPACE--patch-file patch.txt --type='merge'
    

11. Vérifiez la disponibilité de la sous-autorité de certification "Bring Your Own" (BYO). Il faut généralement environ 40 minutes pour que l'autorité de certification soit prête :

    kubectl -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'
    

    La sortie ressemble à ceci :

    {
      "lastTransitionTime": "2024-04-30T22:10:50Z",
      "message": "Certificate authority is ready for use",
      "observedGeneration": 3,
      "reason": "Ready",
      "status": "True",
      "type": "Ready"
    }
    

12. Vérifiez la date d'expiration des certificats d'autorité de certification signés :

    kubectl -n USER_PROJECT_NAMESPACE get secret SECRET_NAME -ojson | jq -j '"echo ", .metadata.name, " $(echo ", .data["tls.crt"], "| base64 -d | openssl x509 -enddate -noout)\n"' | bash
    

Lister les autorités de certification

Pour lister toutes les ressources Certificate Authority Service dans votre instance Distributed Cloud isolée, procédez comme suit :

Utilisez le paramètre certificateauthorities pour lister toutes les ressources CertificateAuthority :

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthorities

La sortie ressemble à ceci :

   NAMESPACE    NAME              READY   REASON   AGE
   foo          root-ca           True    Ready    7h24m
   foo          sub-ca            True    Ready    7h24m