Palo Alto SAML Cert Guide / Okta + Sectigo + PAN-OS

Prepared: April 2, 2026
0% complete

CA-Signed Certificate for Palo Alto SAML Authentication

Complete guide for replacing the self-signed Okta SAML certificate with a Sectigo CA-signed certificate so Palo Alto's "Validate Identity Provider Certificate" option can be enabled.

IdP: Okta
CA: Sectigo
Firewall: Palo Alto (PAN-OS)
Cert Work: Linux Server (OpenSSL)
Key Size: RSA 2048-bit
Prepared: April 2, 2026

Why this is necessary: By default, Okta generates a self-signed certificate for SAML signing. Palo Alto's "Validate Identity Provider Certificate" checkbox requires the SAML assertion to be signed with a CA-issued certificate that chains to a trusted root. Without this, PAN-OS cannot validate the IdP, leaving the SAML integration vulnerable to certificate spoofing.

Your setup: Windows workstations (can't run OpenSSL natively without extra tooling), so all cert generation happens on your Linux server. Sectigo is your CA for signing.

Certificate Flow
Linux Server
— CSR →
Sectigo CA
— Signed Cert →
Linux Server
— .p12 Bundle →
Okta
— Metadata XML →
PAN-OS


Linux generates key + CSR  |  Sectigo signs it  |  PKCS12 uploaded to Okta  |  Updated metadata imported into PAN-OS

1 Phase 1: Generate Private Key + CSR

All commands run on your Linux server. You need OpenSSL installed (it almost certainly is).

1.0 Connect to Your Linux Server from Windows Windows → Linux

  1. Open PowerShell (press Win + X → Windows PowerShell)
  2. SSH into your server:
    ssh your-username@your-server-ip-or-hostname
  3. Enter your password when prompted (or use your SSH key if configured)
  4. Create a working directory to keep all cert files organized:
    mkdir ~/okta-saml-cert && cd ~/okta-saml-cert

Stay connected. Keep this PowerShell/SSH session open throughout Phases 1 and 2. All Linux steps below run in this session.

Pre-flight check: Run openssl version to confirm OpenSSL is available. Any version 1.1+ is fine.

1.1 Generate the Private Key Linux

Generate a 2048-bit RSA private key. This key never leaves the Linux server until you bundle it for Okta.

# Generate 2048-bit RSA private key openssl genrsa -out okta-saml.key 2048

Protect this file. The private key is the crown jewel. If compromised, anyone can forge SAML assertions. Set restrictive permissions immediately:

chmod 600 okta-saml.key

1.2 Generate the Certificate Signing Request (CSR) Linux

The CSR contains your organization's info and the public key. Sectigo will use this to issue the signed cert.

# Generate CSR from the private key openssl req -new -key okta-saml.key -out okta-saml.csr

You will be prompted for the following fields:

FieldWhat to EnterNotes
Country (C)US2-letter country code
State (ST)Your stateFull name, e.g. "Pennsylvania"
Locality (L)Your citye.g. "Pittsburgh"
Organization (O)Your company legal nameMust match Sectigo account
Org Unit (OU)IT / SecurityOptional, but fill if Sectigo requires
Common Name (CN)yourcompany.okta.comYour Okta org URL
Emailadmin@yourcompany.comOptional
Challenge Password(leave blank — press Enter)Do not set this

One-liner alternative (skip the interactive prompts):

openssl req -new -key okta-saml.key -out okta-saml.csr \ -subj "/C=US/ST=Your State/L=Your City/O=Your Company/OU=IT/CN=yourcompany.okta.com"

1.3 Verify the CSR Linux

Before submitting to Sectigo, verify the CSR is valid and contains the correct info.

# Verify and inspect the CSR openssl req -text -noout -verify -in okta-saml.csr

Confirm:

  • Output says verify OK
  • Subject line shows your correct CN, O, C, ST, L
  • Public Key is 2048 bit

1.4 Copy the CSR Contents for Sectigo Linux

You need the CSR text to paste into the Sectigo portal in Phase 2. Print it to the terminal and copy it:

cat okta-saml.csr

Select and copy everything from -----BEGIN CERTIFICATE REQUEST----- through -----END CERTIFICATE REQUEST----- (including those lines). Paste it somewhere on your Windows machine (Notepad is fine) so you have it ready for Step 2.1.

2 Phase 2: Get Sectigo to Sign the Certificate

2.1 Submit CSR to Sectigo Sectigo

  1. Log into your Sectigo Certificate Manager portal
  2. Start a new certificate request
  3. Paste or upload the contents of okta-saml.csr
  4. For certificate type — options depend on your Sectigo subscription:
    • Preferred: "Client Certificate" or "Digital Signing" type (SAML signing doesn't need server auth EKU)
    • Also works: Standard SSL/TLS cert (has more EKUs than needed but will function)
  5. Set the validity period (1 year is standard; check your org's policy)
  6. Complete domain/organization validation as required by Sectigo
  7. Submit and wait for approval

Turnaround time: OV (Organization Validated) certs typically take 1–3 business days. DV (Domain Validated) certs can be minutes. Check which validation level your Sectigo account uses.

2.2 Download the Signed Certificate Sectigo

Once approved, download from Sectigo. You will typically receive:

FileWhat It IsYou Need It For
yourcompany_okta_com.crtYour signed certificateOkta upload + PKCS12 bundle
SectigoRSAOrganizationValidationSecureServerCA.crtIntermediate CA certPKCS12 bundle + PAN-OS import
USERTrustRSAAAACA.crtRoot CA certPAN-OS import (Certificate Profile)

Tip: Rename the files to something sane for easier reference. You'll do this on whichever machine you use for Steps 2.3–2.4.

Choose your path below. Steps 2.3 and 2.4 require OpenSSL to verify the chain and bundle the .p12. You have two options depending on whether you can get the signed certs back onto your Linux server.

Choose Your Path for Steps 2.3 – 2.4

Path A: Linux ServerPath B: Windows (Fallback)
Use whenYou can SCP the signed certs back to the serverFirewall/policy blocks file transfer back to the server
RequiresSCP access to the serverGit for Windows (check if installed: open PowerShell, type git --version)
How it worksUpload certs to server, run OpenSSL thereDownload the private key from the server, run OpenSSL locally via Git

Path A: Finish on Linux Server (SCP certs back)

A1. Upload Signed Certs to Server

Open a new PowerShell window on Windows (keep your SSH session open) and run:

# Run this in PowerShell on Windows (NOT in your SSH session) # Adjust the paths to where you downloaded the files scp C:\Users\YourName\Downloads\yourcompany_okta_com.crt your-username@your-server:~/okta-saml-cert/ scp C:\Users\YourName\Downloads\SectigoRSA*.crt your-username@your-server:~/okta-saml-cert/ scp C:\Users\YourName\Downloads\USERTrust*.crt your-username@your-server:~/okta-saml-cert/

Then back in your SSH session, rename them:

cd ~/okta-saml-cert mv yourcompany_okta_com.crt okta-saml.crt mv SectigoRSA*.crt sectigo-intermediate.crt mv USERTrust*.crt sectigo-root.crt

A2. Verify the Certificate Chain Linux

# Create a CA bundle (intermediate + root) cat sectigo-intermediate.crt sectigo-root.crt > sectigo-ca-bundle.crt # Verify your cert against the chain openssl verify -CAfile sectigo-ca-bundle.crt okta-saml.crt

Expected output: okta-saml.crt: OK

If verification fails: You may be missing an intermediate cert. Check your Sectigo download — some bundles include multiple intermediates. Make sure all of them are in the CA bundle.

A3. Create the PKCS12 (.p12) Bundle Linux

# Create PKCS12 bundle for Okta import openssl pkcs12 -export \ -out okta-saml.p12 \ -inkey okta-saml.key \ -in okta-saml.crt \ -certfile sectigo-intermediate.crt

You will be prompted for an export password. Write this down — you'll need it when uploading to Okta.

Verify the .p12 was created correctly:

openssl pkcs12 -info -in okta-saml.p12 -nokeys

You should see your certificate subject and the Sectigo intermediate listed.

A4. Download Files to Windows

Open PowerShell on Windows and run:

# Run this in PowerShell on Windows (NOT in your SSH session) scp your-username@your-server:~/okta-saml-cert/okta-saml.p12 $HOME\Desktop\ scp your-username@your-server:~/okta-saml-cert/sectigo-root.crt $HOME\Desktop\ scp your-username@your-server:~/okta-saml-cert/sectigo-intermediate.crt $HOME\Desktop\

Path A complete. You should have okta-saml.p12, sectigo-root.crt, and sectigo-intermediate.crt on your Windows Desktop. Skip to Phase 3.

Path B: Finish on Windows (can't SCP certs back to server)

Use this path if your server's firewall blocks inbound SCP, you don't have write access, or your org's security policy prevents uploading files to the server. This uses the OpenSSL binary that ships with Git for Windows.

B1. Confirm Git for Windows Has OpenSSL

Open PowerShell and run:

# Check if Git's OpenSSL is available & "C:\Program Files\Git\usr\bin\openssl.exe" version

If you see a version number (e.g. OpenSSL 1.1.1 or 3.x), you're good. If the path doesn't exist, try:

# Alternative: search for it Get-ChildItem -Path "C:\Program Files\Git" -Recurse -Filter "openssl.exe" | Select FullName

If Git is not installed: Check if your machine has WSL (Windows Subsystem for Linux) — run wsl --list in PowerShell. If WSL is available, open it with wsl and use the regular Linux OpenSSL commands from Path A (your Downloads folder is at /mnt/c/Users/YourName/Downloads/). If neither Git nor WSL is available, you'll need to request one from your IT team.

B2. Create a Working Folder + Rename Certs

# Create a working folder on your Desktop mkdir $HOME\Desktop\okta-saml-cert cd $HOME\Desktop\okta-saml-cert # Copy the Sectigo downloads into it and rename Copy-Item $HOME\Downloads\yourcompany_okta_com.crt -Destination .\okta-saml.crt Copy-Item $HOME\Downloads\SectigoRSA*.crt -Destination .\sectigo-intermediate.crt Copy-Item $HOME\Downloads\USERTrust*.crt -Destination .\sectigo-root.crt

B3. Download the Private Key from Your Linux Server

The private key was generated on the server in Phase 1. You need it locally to create the .p12 bundle.

# Download the private key to your working folder scp your-username@your-server:~/okta-saml-cert/okta-saml.key .\okta-saml.key

Security warning: The private key is now on your Windows machine. This is sensitive material. After you finish Phase 2 and confirm the .p12 works in Okta (Phase 3), delete the local copy immediately:

Remove-Item .\okta-saml.key -Force

The key remains safe on the Linux server. Do not email, upload, or share the .key file.

B4. Verify the Certificate Chain Windows

Set a shortcut variable for Git's OpenSSL, then verify:

# Set an alias so you don't have to type the full path every time $openssl = "C:\Program Files\Git\usr\bin\openssl.exe" # Create CA bundle (combine intermediate + root into one file) Get-Content sectigo-intermediate.crt, sectigo-root.crt | Set-Content sectigo-ca-bundle.crt # Verify the chain & $openssl verify -CAfile sectigo-ca-bundle.crt okta-saml.crt

Expected output: okta-saml.crt: OK

If verification fails: You may be missing an intermediate cert. Check your Sectigo download — some bundles include multiple intermediates. Make sure all of them are in the CA bundle.

B5. Create the PKCS12 (.p12) Bundle Windows

# Make sure $openssl is still set (re-run if you opened a new window) $openssl = "C:\Program Files\Git\usr\bin\openssl.exe" # Create PKCS12 bundle & $openssl pkcs12 -export -out okta-saml.p12 -inkey okta-saml.key -in okta-saml.crt -certfile sectigo-intermediate.crt

You will be prompted for an export password. Write this down — you'll need it when uploading to Okta.

Verify the .p12 was created correctly:

& $openssl pkcs12 -info -in okta-saml.p12 -nokeys

You should see your certificate subject and the Sectigo intermediate listed.

B6. Clean Up the Private Key

Now that the .p12 is created, delete the private key from your Windows machine immediately:

Remove-Item .\okta-saml.key -Force # Verify it's gone Test-Path .\okta-saml.key

Expected output: False

Path B complete. You should have okta-saml.p12, sectigo-root.crt, and sectigo-intermediate.crt in $HOME\Desktop\okta-saml-cert\. Continue to Phase 3.

3 Phase 3: Upload Certificate to Okta

3.1 Upload the PKCS12 to Okta Okta Admin

  1. Log into the Okta Admin Console
  2. Navigate to Applications → Applications
  3. Find and click your Palo Alto Networks SAML app
  4. Go to the Sign On tab
  5. Scroll to the SAML Signing Certificates section
  6. Click "Upload Certificate" (or "Add Certificate" depending on your Okta version)
  7. Select your okta-saml.p12 file
  8. Enter the export password you set in Phase 2
  9. Click Upload

Alternative path: If you don't see the upload option on the app, navigate to Security → Certificates to upload at the org level, then assign it to the app.

3.2 Activate the New Certificate Okta Admin

  1. In the SAML Signing Certificates section, you should now see two certs:
    • The original self-signed cert (currently active)
    • Your new Sectigo CA-signed cert (inactive)
  2. Click the Actions dropdown on the new CA-signed cert
  3. Select "Activate"
  4. Deactivate the old self-signed certificate

Downtime warning: Between activating the new cert in Okta and importing the updated metadata into PAN-OS, SAML authentication to Palo Alto will break. Plan this during a maintenance window or when you can immediately proceed to Phase 4.

3.3 Download Updated Metadata Okta Admin

  1. Still on the Sign On tab of the Palo Alto app
  2. Right-click the "Identity Provider metadata" link
  3. Save as okta-metadata.xml

Critical: You MUST re-download the metadata after changing the certificate. The metadata XML embeds the X.509 certificate. If you use old metadata, PAN-OS will still reference the old self-signed cert and validation will fail.

Optional verification — confirm the metadata contains the new cert:

# Check that the cert in metadata matches your new cert grep "X509Certificate" okta-metadata.xml

The base64 blob should differ from what was there before.

4 Phase 4: Configure Palo Alto (PAN-OS)

4.1 Import the CA Certificate Chain PAN-OS

Import the Root CA

  1. Device → Certificate Management → Certificates
  2. Click Import
  3. Certificate Name: Sectigo-Root-CA
  4. Certificate File: upload sectigo-root.crt
  5. File Format: PEM (Base64 Encoded Certificate)
  6. Click OK

Import the Intermediate CA

  1. Click Import again
  2. Certificate Name: Sectigo-Intermediate-CA
  3. Certificate File: upload sectigo-intermediate.crt
  4. File Format: PEM
  5. Click OK

Note: You do NOT import the Okta SAML signing cert here — that comes in via the metadata XML. You only import the CA certs that PAN-OS needs to validate the chain.

4.2 Create a Certificate Profile PAN-OS

  1. Device → Certificate Management → Certificate Profile
  2. Click Add
  3. Name: Okta-SAML-Cert-Profile
  4. Under CA Certificates, click Add:
    • Select Sectigo-Root-CA
  5. Click Add again (recommended):
    • Select Sectigo-Intermediate-CA
  6. Click OK

Why both? Including the intermediate in the Certificate Profile ensures PAN-OS can build the full chain even if the Okta metadata only includes the end-entity cert (which is common).

4.3 Update the SAML IdP Server Profile PAN-OS

  1. Device → Server Profiles → SAML Identity Provider
  2. Either edit your existing profile or click Add for a new one
  3. Click "Import"
  4. Select the okta-metadata.xml you downloaded in Phase 3
  5. Check the box: "Validate Identity Provider Certificate"
  6. Click OK

This is the key setting. The "Validate Identity Provider Certificate" checkbox is the entire reason for this process. It tells PAN-OS to verify the SAML response signature against a trusted CA chain instead of blindly trusting any certificate.

4.4 Update the Authentication Profile PAN-OS

  1. Device → Authentication Profile
  2. Edit your SAML authentication profile
  3. Ensure these are set:
    • IdP Server Profile: The profile you just updated/created in 4.3
    • Certificate Profile: Okta-SAML-Cert-Profile (from 4.2)
  4. Click OK

4.5 Commit PAN-OS

  1. Click Commit in the top-right of the PAN-OS UI
  2. If using Panorama: also push the configuration to the relevant device groups
  3. Wait for the commit to complete successfully

After commit: SAML authentication is now using the CA-signed certificate. Proceed immediately to Phase 5 to validate.

5 Phase 5: Test & Troubleshoot

5.1 Validation Test PAN-OS

  1. Open an incognito / private browser window (avoids cached sessions)
  2. Navigate to your Palo Alto portal:
    • GlobalProtect Portal: your VPN login page
    • Admin UI: if SAML is enabled for admin access
    • Captive Portal: if using SAML for network auth
  3. You should be redirected to Okta
  4. Authenticate with your Okta credentials
  5. You should be redirected back to Palo Alto and logged in

Success looks like: Normal SSO flow, no certificate errors, landed back in the Palo Alto portal authenticated. The user experience is identical to before — the improvement is invisible (and that's the point).

5.2 Troubleshooting Reference

SymptomLikely CauseFix
"Certificate validation failed" Missing intermediate CA in PAN-OS Certificate Profile Import the Sectigo intermediate cert and add it to the Certificate Profile
SAML loop / never redirects back Metadata not re-imported after cert swap Re-download metadata from Okta (Phase 3.3) and re-import into PAN-OS (Phase 4.3)
"Invalid signature" error Old self-signed cert still active in Okta Verify the CA-signed cert is active and the self-signed is deactivated in Okta
Can't upload .p12 to Okta Wrong export password or key mismatch Recreate the .p12 bundle (Phase 2.4) and verify the password
"Untrusted certificate" in PAN-OS logs Root CA cert not imported into PAN-OS Import sectigo-root.crt into Device → Certificates
Commit fails with certificate error Certificate Profile references a cert that wasn't imported Check that both Sectigo certs show up under Device → Certificates
Where to Find Logs in PAN-OS ▶
  • Monitor → Logs → System — filter for saml or auth
  • Monitor → Logs → Authentication — shows SAML auth attempts
  • CLI: show log system subtype eq auth
  • CLI: debug sslmgr view to inspect certificate state
Verify Certificate from CLI ▶

On the PAN-OS CLI, you can check that certs are properly loaded:

# Show all imported certificates > show sslmgr-store certificate # Show SAML IdP config > show authentication saml-idp

Master Checklist

Click each item as you complete it. Progress is saved in your browser.

Phase 1: Generate Key + CSR (Linux Server)

  • SSH into Linux server and create ~/okta-saml-cert working directory
  • Generate RSA 2048-bit private key (okta-saml.key)
  • Set restrictive permissions on key file (chmod 600)
  • Generate CSR with correct org info and Okta CN (okta-saml.csr)
  • Verify CSR — output shows "verify OK" with correct subject
  • Copy CSR contents (cat okta-saml.csr) and save to Notepad on Windows

Phase 2: Sectigo Signing

  • Submit CSR to Sectigo portal
  • Complete domain/org validation
  • Download signed cert + intermediate + root
  • Verify certificate chain (openssl verify returns OK) — Path A: on server, Path B: on Windows via Git OpenSSL
  • Create PKCS12 bundle (okta-saml.p12) and record export password
  • Confirm .p12, sectigo-root.crt, sectigo-intermediate.crt are on your Windows Desktop
  • If Path B: delete okta-saml.key from Windows (Remove-Item)

Phase 3: Okta Configuration

  • Upload .p12 to Okta Palo Alto SAML app
  • Activate the new CA-signed certificate
  • Deactivate the old self-signed certificate
  • Download updated IdP metadata XML

Phase 4: PAN-OS Configuration

  • Import Sectigo Root CA cert into PAN-OS
  • Import Sectigo Intermediate CA cert into PAN-OS
  • Create Certificate Profile with both CA certs
  • Import updated Okta metadata into SAML IdP Server Profile
  • Enable "Validate Identity Provider Certificate" checkbox
  • Link IdP Server Profile + Certificate Profile in Authentication Profile
  • Commit configuration (and push to device groups if using Panorama)

Phase 5: Validation

  • Test SAML login in incognito browser — redirects to Okta and back
  • Verify no certificate errors in PAN-OS System logs
  • Confirm authentication succeeds for at least one additional test user
  • Document cert expiration date and set renewal reminder