Our certificate in our TLS store will expire shortly; we’ve uploaded the new certificate as the update certificate function did not work for us.
In our dev environment we’ve removed the old certificate and when visiting any endpoint; it still has the old certificate and not the new one. We’ve tried this on multiple machines / devices and the result is the same.
Have we missed a step? We’ve even completely removed the TLS store and re added it, and even without a TLS store the endpoint continued to serve with the old certificate.
Currently in our production TLS store we have both the new and old certificate and are hoping that when the certificate expires, the new one will be served instead.
Some guidance on this would be much appreciated. I believe we are using public cloud.
Are you using references to the keystore and truststore ?
This is a bit of a tricky part of the administrative surface area for Apigee public cloud. The short summary is, if you do not use references, if your config is something like this in your virtual hosts:
<KeyStore>myKeystore</KeyStore>
<TrustStore>myTruststore</TrustStore>
…then you must contact Apigee support to change these things. :[
I dislike that operating model. It’s unwieldy and non-agile. But that’s how it works in Apigee Edge.
Here’s the relevant documentation: https://cloud.google.com/apigee/docs/api-platform/system-administration/options-configuring-tls#about-setting-the-%3Ckeystore%3E-and-%3Ctruststore%3E-elements
There is a workaround mentioned in the documentation: use variables. It looks like this:
<KeyStore>{variable-containing-name-of-keystore}</KeyStore>
<TrustStore>{variable-containing-name-of-truststore}</TrustStore>
I don’t believe that works for VirtualHosts ! It works for HTTPTargetConnection. (The southbound (outbound?) side of an Apigee proxy)
Anyway, the bottom line: I think you need to contact Apigee support to get sorted out.
I think they are talking about Virtual Host cert. Is this OPDK?
Router(nginx) might load old certificates and not pulling a new one from zk(?)
go to your /opt/nginx/conf.d and cat on every cert you see there to see if they’re updated
1 Like
I think maybe not OPDK, because
I believe we are using public cloud.
1 Like
Apigee vH(mainly reference to mTLS changes to keystore/truststore reference) changes are always interesting & always be prepared to open a case and plan it accordingly (this is not very often admin task but has definitely little not elegant way)..Often times it doesn’t reflect & require recycle of routers.
In on-prem it is simple to validate in /opt/nginx/conf.d path and confirm & take action.
Tip: Each time we add we new client certificate we would run below command against the mTLS host & check client certificate list to confirm as well.
openssl s_client -connect host:443