How can I get TLS information in apigee?

[James_wang]

Hi Apigee team,

Here we want to record some TLS  information(mainly want to know the expiration time of the TLS certificate of the service deployed on apigee, of course other information is also useful) in the Traffic log in apigee, could  you help to advise? Thank you in advance:

I drew a simple flowchart, client (the user requesting the api deployed on apigee), apigee (forwarding the client's request to the virtual-host through nginx and then to the api provider), backend (configured in the target server's specific background service).

1. Regarding apigee, I know that apigee provides some flow variables, which allow us to easily get information such as TLS version and password and record them in Traffic Flow <MessageLogging>.
https://docs.apigee.com/api-platform/system-administration/tls-vars 

2. Regarding the client, when the client provides a TLS/SSL certificate, we can get client.cn client.organization.unit and tls.client.cert.fingerprint tls.client.raw.cert (the last two prefixes are tls. Maybe need to set <ClientProperties> to true). But I didn't find a certificate authority (CA), could you please advide? In addition, there also not found notBefore and notAfter, I tried to use $ssl_client_v_start; $ssl_client_v_end; from nginx and put them in the request header and then log them in Traffic Flow <MessageLogging>, I am not sure if this is the best practice, could you please advide? Thanks.
https://docs.apigee.com/api-platform/system-administration/tls-vars 
https://docs.apigee.com/api-platform/reference/variables-reference#client 

conf_load_balancing_load.balancing.driver.nginx.server.ssl.template.extra2=proxy_set_header...

3. Regarding the Target server, I know that we also have some flow variables, but I can't find the fingerprint, certificate authority (CA), notBefore and notAfter, etc. We hope to be able to record them in the Traffic log to realize before the certificate expires. 
https://docs.apigee.com/api-platform/reference/variables-reference#target 

[James_wang]

Hello team,

@dchiesa1 @dknezic @imesh @apickelsimer @atoombs  Could you help? Thank you in advance. 

[dchiesa1]

I think you should not build monitoring for compliance of certificates, into the API proxy. 

I recommend that you use a separate monitoring or check probe that checks endpoints for TLS certs.  In that monitoring probe you can implement all the "SSL Labs" types of checks that you wish - check for old TLS versions, soon-to-expire certs, certs with the "wrong" CA, certs with weak keys or ciphers... 

There is a basic open source tool that can help evaluate expiry. https://github.com/Matty9191/ssl-cert-check. It builds on openssl . And there are others., of varying capabilities. Read more on owasp.org. One of the best, I believe, is sslyze., a python script that can check TLS versions, certificate types, certificate signatures, cipher suites,  expiry... And there's an API for sslyze , so you can write your own python script to check the things you want to check, against the conventions you have. 

So there are options for good, mature, well-tested open source tools. Pick one or more of those tools, and then log the results of THAT.  

If I were doing this I would configure this as a Google Cloud Run job (bash, python), set to run once per day, and iterate over a set of endpoints, checking the certs of all of them, and logging the results to google cloud logging (which happens automatically in the stdout of a Google Cloud job).  You could even do this for "internal" endpoints that are not exposed outside your GCP VPC.  If you want that check to be really clever, you could build the logic in the job so that it extracts the set of URLs to check from the target endpoints in all the API proxies in your environment, and probe THOSE specific endpoints. 

But you don't have to use GCP Cloud Run Jobs. That's an easy way to do it, but you could use any task scheduler that can run a bash script. Your team probably has something like this already, for daily tasks, other daily or weekly checks, and so on. 

I think trying to use the API proxy to do all this checking and logging is the wrong approach.  You could do it there, but it's not the right tool for the job.  Build a separate check. Embed it in a task scheduler.  Plug it into your SIEM.  

btw this should be the same monitoring tool you use for your websites. the TLS for API endpoints has the same requirements as for web endpoints. So it's possible your organization already has a TLS check tool in place. Maybe you can just use that.