Hi, My issue is similar to the discussion on this other thread.
I was told that we had a proxy that was connecting to a backend server, and the backend server did not have a certificate, so I started to do some troubleshooting.
I created a targetServer like this:
{
"host": "revoked.badssl.com",
"isEnabled": true,
"name": "badssl-testing",
"port": 443,
"sSLInfo": {
"ciphers": [],
"clientAuthEnabled": "false",
"commonName": {
"value": "*.badssl.com",
"wildcardMatch": true
},
"enabled": "true",
"ignoreValidationErrors": false,
"protocols": [],
"trustStore": "trustStore-outbound"
}
}
The proxy has this TargetConnection defined
<HTTPTargetConnection>
<LoadBalancer>
<Server name="badssl-testing"/>
</LoadBalancer>
<Path/>
</HTTPTargetConnection>
My browser tells me that ârevoked.badssl.comâ does not have a certificate, so there shouldnât be anything in the TrustStore (âtrustStore-outboundâ), nor should the âcommonNameâ match.
However, I still get a â200 OKâ response from the proxy.The trace shows that a successful HTTPS connection was established:
Have I missed something? As far as I can tell, this should not be working, yet it does.
Hi @mark_hammelman ,
It looks like your target configuration is correct, but the confusion may come from how the browser and Apigee handle certificates, especially in terms of revoked certificates.
When your browser says ârevoked.badssl.comâ does not have a certificate, itâs actually showing a slightly misleading error. The site does have a certificate, but it has been revoked. Browsers like Firefox or Chrome have built-in features like Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP) to automatically check the revocation status of certificates. For example, in Firefox, youâll see a specific error like SEC_ERROR_REVOKED_CERTIFICATE, indicating the certificate was revoked.
Your Apigee proxy behaves differently because Apigee doesnât automatically perform revocation checks like CRL or OCSP. While your proxy correctly validates certificates using the trustStore, it doesnât check for revocation status out-of-the-box. This explains why youâre still getting a â200 OKâ response, even though the certificate is revoked.
So, the key difference that browsers handle revocation checks automatically, but Apigee does not.
What you can do:
-
Manually Update Revoked Certificates: If you need to ensure your certificates are up to date, youâll need to manually update or replace them when they are revoked. You can follow the official Apigee guide on how to update or replace SSL certificates here.
-
Test in Firefox: Open ârevoked.badssl.comâ in Firefox to see a more accurate error message (SEC_ERROR_REVOKED_CERTIFICATE) and confirm that the certificate is revoked, not missing.
Let me know if this clears things up! Feel free to reach out if you need any help.
We use Apigee Edge Public Cloud. Iâm not familiar with how to âManually configure CRLâ in a keystore. Is this supported in our case?
After double-checking, I can confirm that Apigee doesnât support CRL (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol) for revocation checking. This means that Apigee will validate the presented certificate against the trustStore, but it wonât automatically check whether the certificate has been revoked.
To monitor the status of certificates, many organizations rely on corporate CAs, which typically provide notifications for revoked or expired certificates. Additionally, enterprises often use Certificate Lifecycle Management (CLM) platforms, which offer centralized monitoring for revocation, expiration, and other issues. These platforms provide features like automated alerts and revocation status tracking through external APIs or CA endpoints.
Without these built-in checks in Apigee, youâll need to rely on external monitoring solutions or manual certificate audits to stay informed about the status of your certificates.
1 Like