Certificate Authority Service in GCP - Commands & Configuration

Introduction

Sometimes you need to create and manage digital certificates to keep your websites and apps secure. Google Cloud's Certificate Authority Service helps you create these certificates easily and safely without needing to run your own certificate system.

When you want to issue SSL/TLS certificates for your internal company websites without buying from external providers.

When you need to create certificates for devices or apps that must trust each other securely.

When you want to automate certificate creation and renewal to avoid manual errors.

When you want to keep control over your certificates inside your cloud environment.

When you need to create a trusted chain of certificates for your organization's security.

Config File - ca-config.yaml

ca-config.yaml

apiVersion: privateca.googleapis.com/v1
kind: CertificateAuthority
metadata:
  name: my-root-ca
  location: us-central1
spec:
  tier: ENTERPRISE
  type: SELF_SIGNED
  config:
    subjectConfig:
      subject:
        commonName: "My Root CA"
        organization: "Example Corp"
        countryCode: "US"
    keySpec:
      cloudKmsKeyVersion: "projects/example-project/locations/us-central1/keyRings/my-keyring/cryptoKeys/my-key/cryptoKeyVersions/1"
    lifetime: 87600h
    caOptions:
      isCa: true
      maxIssuerPathLength: 1

This YAML file defines a root Certificate Authority named my-root-ca in the us-central1 region.

tier sets the service level to enterprise for full features.

type is self-signed, meaning this CA signs its own certificate.

subjectConfig sets the identity details of the CA.

keySpec points to a Cloud KMS key that secures the CA's private key.

lifetime is how long the CA certificate is valid (10 years here).

caOptions marks this as a CA and limits the certificate chain length.

Commands

This command creates the root Certificate Authority using the configuration file. It sets up the CA in the specified region with the defined settings.

Terminal

gcloud privateca roots create my-root-ca --location=us-central1 --config=ca-config.yaml

Expected Output

Created Certificate Authority [my-root-ca].

→

--location - Specifies the region where the CA is created.

→

--config - Points to the YAML file with CA configuration.

This command shows details about the created root CA to confirm it was set up correctly.

Terminal

gcloud privateca roots describe my-root-ca --location=us-central1

Expected Output

name: projects/example-project/locations/us-central1/certificateAuthorities/my-root-ca

state: ENABLED

config:

  subjectConfig:

    subject:

      commonName: My Root CA

      organization: Example Corp

      countryCode: US

  keySpec:

    cloudKmsKeyVersion: projects/example-project/locations/us-central1/keyRings/my-keyring/cryptoKeys/my-key/cryptoKeyVersions/1

lifetime: 87600h

caOptions:

  isCa: true

  maxIssuerPathLength: 1

→

--location - Specifies the region of the CA to describe.

This command creates a new certificate signed by the root CA for the domain example.com, useful for securing websites or services.

Terminal

gcloud privateca certificates create my-cert --issuer=my-root-ca --location=us-central1 --certificate-template=server-auth --subject="CN=example.com"

Expected Output

Created certificate [my-cert].

→

--issuer - Specifies which CA signs the certificate.

→

--certificate-template - Defines the certificate usage, here for server authentication.

→

--subject - Sets the identity details for the certificate.

This command shows details about the issued certificate to verify its properties and status.

Terminal

gcloud privateca certificates describe my-cert --location=us-central1

Expected Output

name: projects/example-project/locations/us-central1/certificates/my-cert

issuer: projects/example-project/locations/us-central1/certificateAuthorities/my-root-ca

subject:

  commonName: example.com

state: ACTIVE

pemCertificate: -----BEGIN CERTIFICATE-----\nMIIB...\n-----END CERTIFICATE-----

→

--location - Specifies the region of the certificate.

Key Concept

If you remember nothing else from this pattern, remember: Certificate Authority Service lets you create and manage your own trusted certificates securely inside Google Cloud.

Common Mistakes

Not specifying the correct location flag when creating or describing the CA or certificates.

The commands will fail or show no results because the service is regional and needs the location to find resources.

Always include the --location flag with the correct region for your CA and certificates.

Using a Cloud KMS key that does not exist or is in a different region than the CA.

The CA creation will fail because the key must be accessible and in the same region.

Create or use a Cloud KMS key in the same region as your CA before creating the CA.

Omitting the subject details in the CA config file.

The CA will not have a proper identity, causing errors or invalid certificates.

Always fill in the subjectConfig section with meaningful values like commonName and organization.

Summary

Create a root Certificate Authority using a YAML config file with gcloud.

Verify the CA details to ensure it is active and correctly configured.

Issue certificates signed by the CA for your domains or services.

Check issued certificates to confirm their properties and status.

Practice

1. What is the main purpose of the Certificate Authority Service in Google Cloud?

easy

A. To store large amounts of data securely

B. To create and manage digital certificates for secure communication

C. To monitor network traffic in real-time

D. To provide virtual machines for computing tasks

Solution

1. Step 1: Understand the role of Certificate Authority Service

   This service is designed to create and manage digital certificates that prove identity and secure communication.

2. Step 2: Compare with other options

   Options A, C, and D describe other cloud services unrelated to certificate management.

3. Final Answer:

   To create and manage digital certificates for secure communication -> Option B

4. Quick Check:

   Certificate Authority Service = Manage digital certificates [OK]

Hint: Remember: Certificate Authority = issues certificates [OK]

Common Mistakes:

• Confusing certificate management with data storage
• Thinking it monitors network traffic
• Assuming it provides computing resources

2. Which of the following is the correct way to create a self-signed certificate authority using gcloud CLI?

easy

A. gcloud privateca certificates create my-cert --issuer=my-root --location=us-central1

B. gcloud privateca subordinate create my-sub --subject="CN=My Sub CA" --location=us-central1

C. gcloud privateca roots create my-root --subject="CN=My Root CA" --pool=my-pool --location=us-central1

D. gcloud privateca revoke my-cert --location=us-central1

Solution

1. Step 1: Identify command for self-signed root CA creation

   The command gcloud privateca roots create is used to create a self-signed root certificate authority.

2. Step 2: Verify other options

   gcloud privateca subordinate create my-sub --subject="CN=My Sub CA" --location=us-central1 creates a subordinate CA, C creates a certificate, and D revokes a certificate, so they are incorrect for creating a self-signed CA.

3. Final Answer:

   gcloud privateca roots create my-root --subject="CN=My Root CA" --pool=my-pool --location=us-central1 -> Option C

4. Quick Check:

   Self-signed CA uses 'roots create' command [OK]

Hint: Self-signed CA uses 'roots create' command in gcloud [OK]

Common Mistakes:

• Using subordinate create command for root CA
• Confusing certificate creation with CA creation
• Trying to revoke instead of create

3. Given the following code snippet, what will be the output of the command?

gcloud privateca certificates list --location=us-central1 --ca-pool=my-pool

medium

A. Lists all certificates issued by the CA pool named 'my-pool' in us-central1

B. Deletes all certificates in the CA pool 'my-pool'

C. Creates a new certificate in the CA pool 'my-pool'

D. Shows the details of the CA pool 'my-pool' without certificates

Solution

1. Step 1: Understand the command purpose

   The command gcloud privateca certificates list lists certificates issued by a specified CA pool.

2. Step 2: Analyze parameters

   The parameters specify the location and the CA pool name, so the output will be the list of certificates issued by that pool in that location.

3. Final Answer:

   Lists all certificates issued by the CA pool named 'my-pool' in us-central1 -> Option A

4. Quick Check:

   Certificates list command outputs issued certificates [OK]

Hint: List command shows issued certificates, not create or delete [OK]

Common Mistakes:

• Thinking list deletes or creates certificates
• Confusing CA pool details with certificate list
• Ignoring the location parameter

4. You tried to create a subordinate CA with the command:

gcloud privateca subordinate create my-sub --pool=my-pool --issuer=my-root --location=us-central1

But got an error about missing permissions. What is the most likely cause?

medium

A. You do not have the required IAM role to create subordinate CAs

B. The command syntax is incorrect; 'subordinate create' is invalid

C. The location 'us-central1' does not support subordinate CAs

D. The issuer 'my-root' does not exist in the project

Solution

1. Step 1: Understand permission errors

   Permission errors usually mean the user lacks the required IAM role or permission to perform the action.

2. Step 2: Check command validity and other options

   The command syntax is valid, 'us-central1' supports subordinate CAs, and issuer existence errors usually mention not found, not permissions.

3. Final Answer:

   You do not have the required IAM role to create subordinate CAs -> Option A

4. Quick Check:

   Permission error = missing IAM role [OK]

Hint: Permission errors usually mean missing IAM role [OK]

Common Mistakes:

• Assuming syntax error causes permission issues
• Ignoring IAM roles and permissions
• Confusing location support with permission problems

5. You want to set up a secure internal network where your services trust certificates issued by your own CA. Which steps should you follow using Certificate Authority Service to achieve this?

hard

A. Create multiple root CAs and assign each service a different root CA

B. Create only a self-signed root CA and issue certificates directly from it to services

C. Use Google-managed CA and import your certificates manually to services

D. Create a root CA, create a subordinate CA signed by the root, then issue certificates from the subordinate CA to services

Solution

1. Step 1: Understand best practice for internal CA hierarchy

   Best practice is to create a root CA and then a subordinate CA signed by the root to issue certificates, improving security and manageability.

2. Step 2: Evaluate options

   Create only a self-signed root CA and issue certificates directly from it to services is less secure because issuing directly from root CA is discouraged. Use Google-managed CA and import your certificates manually to services uses Google-managed CA, not your own. Create multiple root CAs and assign each service a different root CA creates unnecessary complexity.

3. Final Answer:

   Create a root CA, create a subordinate CA signed by the root, then issue certificates from the subordinate CA to services -> Option D

4. Quick Check:

   Root CA + subordinate CA hierarchy = secure internal trust [OK]

Hint: Use root CA + subordinate CA for secure internal certificates [OK]

Common Mistakes:

• Issuing certificates directly from root CA
• Using Google-managed CA instead of own CA
• Creating multiple root CAs unnecessarily