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"
}
}
<HTTPTargetConnection>
<LoadBalancer>
<Server name="badssl-testing"/>
</LoadBalancer>
<Path/>
</HTTPTargetConnection>
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.
Solved! Go to Solution.
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.
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.