How to Generate a CSR on Google Cloud Platform

This tutorial shows you how to generate a CSR (Certificate Signing Request) for Google Cloud Platform using OpenSSL, then how to upload the signed certificate to the right Google Cloud service. Google Cloud has no built-in form that creates a CSR for you, so the request and the matching private key are generated with OpenSSL, either in Google Cloud Shell or on your local Linux, macOS, or Windows machine.

The exact upload step depends on which service serves your traffic: Certificate Manager (modern, for Cloud Load Balancing, Cloud Run, and Cross-Cloud Network), the older Compute Engine SSL certificates resource (still valid for classic load balancers), or App Engine SSL certificates.

When you actually need a CSR on Google Cloud

Most GCP services can provision and auto-renew a free, Google-managed certificate for you (currently through Let’s Encrypt). If a managed certificate fits your use case, you do not need a CSR at all. Generate a CSR and use a self-managed (third-party) certificate only when one of the following applies:

• You need a wildcard certificate (Google-managed certificates do not cover *.example.com).
• You need OV or EV validation (Google-managed certificates are DV only).
• Your policy or contract requires a specific Certificate Authority.
• You already own a valid certificate and want to redeploy it on GCP.
• You are bringing your own certificate to a service that does not auto-provision one for you (for example, a Compute Engine VM where you terminate TLS yourself).

If none of the above is true, skip the CSR work and use Google-managed certificates instead (see our guides for App Engine and Google Cloud Platform).

Generate the CSR for Google Cloud Platform

If you already generated your CSR and have the signed certificate from your CA, skip ahead to Upload the signed certificate to Google Cloud. You have two ways to create a CSR for GCP:

• Use our CSR Generator to produce the CSR and private key in your browser, then paste the CSR during your SSL order.
• Generate the CSR yourself with OpenSSL, either in Google Cloud Shell or on your local machine. The steps below cover this path.

Step 1: Open a shell with OpenSSL

OpenSSL ships on every recent Linux distribution and on macOS, and is preinstalled in Google Cloud Shell. Pick whichever is easiest:

• Google Cloud Shell: sign in to the Google Cloud Console, select your project, then click Activate Cloud Shell in the top bar. The console window opens at the bottom of the page in your home directory (/home/user). Cloud Shell needs an active project; if you do not have one, follow Google’s Cloud Shell quickstart to create one first.
• Local Linux or macOS: open a terminal in any folder you can write to.
• Windows: install OpenSSL (for example through OpenSSL on Windows) and run the commands in a PowerShell or Command Prompt window. Alternatively, run them in Cloud Shell.

You can generate the CSR in the default directory or any other location of your choice. The two files OpenSSL writes (CSR and private key) are plain text, so you can copy them off the machine when you are done.

Step 2: Run the OpenSSL command

Run the following command in your shell. Replace yourdomain with your actual domain (for example, example.com):

openssl req -new -newkey rsa:2048 -nodes \
  -keyout yourdomain.key -out yourdomain.csr \
  -addext "subjectAltName = DNS:yourdomain.com,DNS:www.yourdomain.com"

What each flag does:

• -new creates a new CSR.
• -newkey rsa:2048 generates a new 2048-bit RSA private key alongside the CSR. Use rsa:3072 or rsa:4096 if your policy requires a larger key.
• -nodes writes the key without a passphrase (Google Cloud Certificate Manager and most GCP services require an unencrypted private key).
• -keyout and -out are the output paths for the key and CSR.
• -addext “subjectAltName=DNS:…” embeds Subject Alternative Names (SANs) directly. Every modern browser and CA requires the SAN extension, even for single-domain certificates, so include both the apex (yourdomain.com) and any www variant you plan to serve. For a wildcard, list *.yourdomain.com as well.

To request an ECC certificate instead of RSA (smaller, faster, supported by Certificate Manager as P-256 or P-384), replace -newkey rsa:2048 with -newkey ec -pkeyopt ec_paramgen_curve:P-256.

Step 3: Fill in the CSR details

OpenSSL prompts you for the certificate’s identity fields. Enter them as follows:

• Country Name: the two-letter ISO code of the country where your organization is legally registered (for example, US).
• State or Province Name: the full name of the state or region (for example, Washington). Do not abbreviate.
• Locality Name: the city (for example, Seattle).
• Organization Name: the legal name of your organization. For a Domain Validation certificate, leave this blank.
• Organizational Unit Name: deprecated by the CA/Browser Forum, so leave it blank.
• Common Name: the fully qualified domain name (FQDN) you want to secure, for example www.yourdomain.com. For a wildcard, enter *.yourdomain.com. The Common Name must also be present in the SAN list.
• Email Address: a valid contact email (or leave blank).
• A challenge password and An optional company name: leave both blank. Press Enter to skip.

Double-check what you entered, then press Enter. OpenSSL writes two files in the current directory:

• yourdomain.csr, the CSR you submit to your Certificate Authority.
• yourdomain.key, the private key. Keep this file private; you will need it again when you upload the issued certificate to Google Cloud.

Step 4: Submit the CSR to your Certificate Authority

Open yourdomain.csr in any text editor and copy the whole block, including the —–BEGIN CERTIFICATE REQUEST—– and —–END CERTIFICATE REQUEST—– markers. Paste it into the CSR field during your SSL order with the CA.

Before submitting, you can verify the CSR contents with our CSR Decoder: it shows the Common Name, SAN list, key type, and key length so you can catch typos before the CA does.

Complete the validation steps the CA asks for (DNS, file-based, or email). Once the certificate is issued, the CA sends you the signed certificate and the intermediate (CA-bundle) file. Continue with the upload below.

Upload the signed certificate to Google Cloud

The right upload command depends on which Google Cloud service terminates HTTPS for you. Before any of them, combine your leaf certificate and the intermediate chain into a single PEM file (leaf first, intermediates after):

cat yourdomain.crt yourdomain.ca-bundle > fullchain.crt

Certificate Manager also requires the private key in PKCS#8 form. If your key starts with —–BEGIN RSA PRIVATE KEY—– (PKCS#1), convert it:

openssl pkcs8 -topk8 -nocrypt -in yourdomain.key -out yourdomain_pkcs8.key

Certificate Manager (recommended for new deployments)

Certificate Manager is the modern Google Cloud service for TLS certificates and is the recommended path for Cloud Load Balancing, Cloud Run, and most new deployments. Upload the self-managed certificate with one command:

gcloud certificate-manager certificates create MY_CERT \
  --certificate-file=fullchain.crt \
  --private-key-file=yourdomain_pkcs8.key

Replace MY_CERT with a name of your choice. The certificate now lives in Certificate Manager but does not serve traffic until you attach it through a certificate map. For the full deployment steps (map, map entry, target HTTPS proxy), see our guide on installing an SSL certificate on Google Cloud Platform.

Classic Cloud Load Balancing (Compute Engine SSL certificates)

For an existing classic external HTTPS load balancer that uses Compute Engine SSL certificate resources (not yet migrated to Certificate Manager), upload with:

gcloud compute ssl-certificates create MY_CERT \
  --certificate=fullchain.crt \
  --private-key=yourdomain.key \
  --global

Drop --global and add --region=YOUR_REGION for a regional load balancer. Attach the resource to the load balancer’s target HTTPS proxy with gcloud compute target-https-proxies update. New deployments should use Certificate Manager instead; it is the path Google recommends going forward.

App Engine

For App Engine, the upload uses the App Engine SSL certificate resource and the unencrypted PEM private key (no PKCS#8 conversion required). App Engine SSL certificates have a stricter key policy than Certificate Manager: only RSA keys of 2048 bits or fewer are accepted, and ECC keys are not supported. If you generated a 3072 or 4096-bit RSA key in Step 2, regenerate the CSR with -newkey rsa:2048 before submitting it to your CA for an App Engine deployment.

gcloud app ssl-certificates create \
  --display-name="example.com 2026" \
  --certificate=fullchain.crt \
  --private-key=yourdomain.key

Then bind the returned certificate ID to a mapped custom domain and switch that mapping to manual management. See our App Engine SSL installation guide for the full workflow, including how to switch back to a free Google-managed certificate later.

Compute Engine VMs (you manage the OS)

If you terminate TLS directly on a Compute Engine VM (Apache, Nginx, IIS, Tomcat, and similar), treat the VM as a normal server. Generate the CSR there, install the issued certificate the same way you would on any Linux or Windows host, and reload the web server. Our family of SSL installation guides covers each web server in detail.

Verify the CSR and the deployed certificate

Before submitting the CSR, decode it locally to confirm the Common Name, SAN list, key type, and key length:

openssl req -in yourdomain.csr -noout -text

Or paste the CSR into our CSR Decoder for the same information in your browser.

Once the certificate is deployed on your load balancer, App Engine domain, or VM, scan the live domain with our SSL Checker to confirm the certificate, chain, and protocol support are correct.