SSL is one of those topics that every senior Pega developer eventually needs to understand properly. This is a practical walkthrough of how it works and how to implement it.
Why SSL Matters
SSL does three things that matter for enterprise applications.
Data encryption – any data travelling between client and server is encrypted using public and private keys. Even if someone intercepts it, they cannot read it without the private key.
Data integrity – encrypted data cannot be tampered with in transit. What was sent is what arrives.
Authentication – certificates establish trust between parties. The server presents a certificate, the client checks whether it trusts that certificate, and the connection is allowed or denied accordingly.
HTTPS is SSL in practice. Any time you see HTTPS in a URL, those three guarantees are in place.
How Certificates and Keys Work
A server has a certificate signed by a certificate authority. When a client connects, the server presents that certificate. The client checks its trust store – the collection of certificates it trusts. If the server’s certificate was signed by a trusted authority, the connection proceeds. If not, the client refuses or warns.
Public and private keys are what make the encryption work. The server shares its public key. The client uses it to encrypt data sent to the server. Only the server’s private key can decrypt it. The private key never leaves the server.
Self-signed certificates – ones you create yourself without a recognised certificate authority signing them – will always trigger trust warnings in browsers and API clients, because they are not signed by anyone the client already trusts. The fix is to manually import the certificate into the client’s trust store.
Configuring HTTPS on Pega’s Tomcat Server
SSL for Pega is configured in the server.xml file under the Tomcat conf directory. You add an HTTPS connector specifying the port, the keystore file location and the keystore password. The keystore holds your server’s certificate and private key – created using the Java keytool command.
Make sure the CN name in your certificate matches your server’s hostname. For local development that means localhost. In production it must match your actual domain.
Trusting Certificates in Clients
For a browser – import the P12 file from your keystore into the browser’s trusted root certificate authorities. After this, the browser will trust the certificate and show the connection as secure rather than flagging it as unsafe.
For Postman – go to Settings, navigate to Certificates and add the PEM file as the CA certificate for your host. Postman will then trust the certificate when making API calls to that server. This is the right approach for testing rather than simply disabling SSL verification – it mimics what a real application would do.
One-Way SSL vs Two-Way SSL
With one-way SSL, only the server has a certificate installed. The server presents its certificate to connecting clients. Clients that trust the certificate can connect. Clients that do not trust it are blocked. This is the standard HTTPS setup most applications use.
With two-way SSL (also called mutual SSL), both the server and the client have certificates. The server presents its certificate to the client AND requires the client to present its own certificate back. The server checks whether it trusts the client’s certificate before allowing the connection. This provides an extra layer of security and is used in machine-to-machine integrations where both sides need to authenticate each other.
Watch the Full Walkthrough
In the video below I walk through creating a keystore with the Java keytool, configuring HTTPS on Tomcat, resolving the self-signed certificate trust issue in a browser and in Postman, and successfully accessing a Pega API over HTTPS from Postman with basic authentication.
SSL is one of those topics where the theory makes more sense once you see the browser throw a certificate error and then fix it. This video shows exactly that.
