Understanding the difference between TLS certificates in Viya

[thesasuser]

Hello
While working on configuration of SAS Viya4 for using customer provided ca certificates, I came across these terms.
trustedcerts.pem, sas-ingress-certificate.pem, sas-ingress.key and sas-ingress-CA-certificate.pem.
Wondering if some one can help me understand these terms?

[angian · Accepted solution]

1. 🗝️ sas-ingress.key — The Private Key

This is the private key for the Ingress Controller (typically NGINX). It is the secret half of the public/private key pair used in TLS handshakes.

• What it does: Used by the Ingress Controller to decrypt incoming HTTPS traffic from browsers/clients.
• Where it lives: Stored inside a Kubernetes secret called sas-ingress-certificate (alongside the signed certificate).
• How it's specified: In customer-provided-ingress-certificate.yaml as tls.key.
• Important: Never expose this file. It must match the public certificate (sas-ingress-certificate.pem).

2. 📄 sas-ingress-certificate.pem — The Signed Server Identity Certificate

This is the public TLS certificate for the Ingress Controller — the certificate presented to browsers and clients when they connect to SAS Viya over HTTPS.

• What it does: Proves the identity of your SAS Viya server to external clients (browsers, APIs, etc.).
• Signed by: Your organization's CA (the one referenced in sas-ingress-CA-certificate.pem).
• Where it lives: Also stored in the Kubernetes secret sas-ingress-certificate, specified as tls.crt in customer-provided-ingress-certificate.yaml.
• Requirement: Must be a wildcard or contain a SAN matching your Ingress FQDN.

3. 🏛️ sas-ingress-CA-certificate.pem — The CA Certificate (Trust Anchor)

This is the Certificate Authority (CA) certificate that signed sas-ingress-certificate.pem. It represents the root (or intermediate) of your PKI trust chain.

• What it does: Allows SAS Viya's internal services (pods) to trust the Ingress certificate. Without this, internal pod-to-pod or pod-to-ingress communication will fail with x509: certificate signed by unknown authority errors.
• When required: Needed when the CA that signed the Ingress certificate is not in the Mozilla trusted CA bundle (i.e., it's a private/corporate CA, not a public one like DigiCert or Let's Encrypt).
• How it's provided: Via customer-provided-ca-certificates.yaml — you place PEM-encoded CA cert files under site-config/security/cacerts/ and reference them in that YAML.
• What it updates: SAS Viya's internal trust stores across all pods (managed by the sas-certframe init container).

📌 If your Ingress cert is signed by a well-known public CA (e.g., Let's Encrypt, DigiCert), you may not need this file since those CAs are already in the Mozilla bundle included in SAS Viya's default trust store.

4. 🗃️ trustedcerts.pem — The Aggregated Trust Store

This is SAS Viya's compiled/aggregated trust store file — a single PEM file that concatenates all trusted CA certificates that SAS services use to verify TLS connections.

• What it does: Acts as the unified CA bundle for all SAS Viya internal services. When a SAS service (e.g., CAS, SAS Logon) makes an outbound TLS connection, it validates the peer's certificate against this file.
• Where it lives: Inside running containers at:

  /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/trustedcerts.pem
  

• What it contains: Mozilla public CA certs + the Ingress CA chain + the SAS internal CA + any additional customer-provided CA certs.
• Managed by: The sas-certframe init container, which builds this file automatically at pod startup by merging all the CA sources.

For the official SAS documentation on this, the SAS Help Center has a comprehensive guide: Configure Network Security and Encryption.