From gateway we connect to a blackened application server where the certificate is expired,if certificate was expired we can't connect, is their any work around to mitigate this for time being by adding some thing in a cluster wide properties for ssl?
Clinet-->Gateway 9.2-->Back-end (cert expired)
As a workaround, you can import the server certificate from the backend server and use it for SSL/TLS connections.
Now the certificate will be used for SSL/TLS connections to the backend server.
My Question was,if a certificate was expired lets say its expired yesterday, still the SSL handshake would be established if i import the cert as per your suggestion above?
I'm sorry. I thought the CA certificates were expired for the backend server.
As far as I know, the CA API Gateway cannot ignore the validation for certificates which are expired or not yet valid.
The Gateway is effectively a client in that transaction and - like most clients - it cannot be configured to ignore certificate expiry dates as part of its validation process during the initial SSL handshake. Some clients do have overrides for this, I believe, but at least in my opinion it is not really a safe option to have in the first place as it potentially opens a new realm for malicious activity without a user/admin knowing about it. If you do believe strongly that this feature should exist, then I would encourage you to file a new idea in the community for consideration in a future version of the CA API Gateway.
Thanks for the clarification and i totally agree. Infact we can't stop the progress of development in lower environment because of this issue ,this kind of issue really sucks few days behind intems of delivery.Any way thanks.
Hi, as an ex datapower admin, I know that in IBM datapower gateways they do have such option not to perform certificate validation. I agree with you that disabling certificate validation creates a new security concerns. however, I faced many times situations in which the backend service certificate was not valid in low envs and project timelines were crucial, so still , i'm wondering if any workaround can be implemented in the gateway ?
As noted already, there is no way to workaround this in the Gateway side. I can imagine a convoluted workaround though (this is untested though) where you route to something else (like a load balancer VIP) that you would control and terminate SSL on it so that the Gateway then won't bother with the backend SSL certificate, and that load balancer could be configured to ignore the validation of the backend certificate. This workflow, I believe, would allow you more control to have a long-running expiry date for a certificate so that you do not have to worry as much about the Gateway running into certificate validation issues. This should alleviate the frequency of these issues, if not altogether eliminate it as you'd have more control.
With that said, between the backend being the root cause (and needing to "up their game" for properly replacing certificates well in advance of their expiry) plus the security issues that can arise from a feature that tells the Gateway to ignore all certificate validation, I personally think it's not worth putting in that feature to simply ignore all certificates. But of course, that's just my own personal opinion, not necessarily the opinion of CA Technologies. So please do feel free to create the feature request as an Idea in this community if you feel that feature should be available to users of the API Gateway.
My personal and preferred method forward would be to just greatly improve the process that seems to be allowing the certificates to expire with frequency in such a critical backend system.
appreciate your thorough answer.