Do you have an automation plan for shorter SSL expiration dates

[CHANGHYUK LEE]

My name is LEE, and I am an engineer working in South Korea.

 

I am writing to inquire about two critical issues we are facing regarding certificate management. For context, the attached image shows the upcoming expiration dates for some of our key certificates.

 

In South Korea, the widespread use of the "MyData" service by financial institutions necessitates mTLS, which means we manage a large number of intermediate certificates on our gateway.

 

Our primary issue is that requests begin to fail whenever an external institution uses an SSL certificate issued from an intermediate certificate with an updated validity period. Traffic from that specific institution continues to fail until we manually re-register the new intermediate certificate. For financial services, an outage of this nature is extremely critical.

 

This process is already causing significant inconvenience for our customers. We are concerned this situation will become untenable as certificate validity periods are set to decrease dramatically: first to 200 days this coming March, and then to just 47 days thereafter.

 

Could you please advise if there are any planned countermeasures or solutions to automate this certificate update process and prevent these critical service disruptions?

 

A second challenge we face is the required gateway restart when replacing the default private key. This downtime also negatively impacts our customers. The increased frequency of replacements due to shorter validity periods (200, 100, and 47 days) will make this a much more frequent problem.

 

Do you have a planned feature to allow for private key replacement without a full gateway restart?

 

Thank you for your time and assistance with these matters.

 

Best regards,

[Joseph Fry]

Lee,

The gateway should not require that intermediate certificates be installed in order to validate a client/server cert during mutual TLS.  You should be able to install just the root CA certificate and mark it as a trust anchor.

The only exception I am aware of is when there are wildcard certificates used.  In that case the gateway will require the full chain in its certificate store if you want mTLS.

I cannot comment on the plans to automate certificate management; however the gateway has extensive API's (restman/graphman) that could be used with your own scripts/tools.

I have not tested myself, but per the documentation, the reboot is only required when changing the default private key if it is assigned to the listen port that your current policy manager session is using.  So in theory you could have a second SSL keys on a second port enabled for policy manager and use it to update the default key without a reboot.  Or just update it using restman/graphman.  

[Gary Vermeulen]

Hi Lee,

In addition to Joseph's response, there are two new preview features that make managing private key changes in the Gateway easier.

• ListenPorts refreshOnKeyChanges (advanced property) - when changing the key assigned to the port, the port is automatically refreshed. Using graphman to update the key is the best approach for future automation, graphman also accepts PEM format.
• Route via HTTP(S) Assertion (new systemProperty) - when any given key you are using for mTLS is updated, a gateway restart is not required.

[Ben Urbanski]

Hello Lee,

Though you can automate a lot of certificate management using the gateway's management APIs today, we definitely are looking at other ways of automating certificate management and perhaps through simple configuration. Customers have long asked for this, but it's receiving more attention now because of the CA/Browser Forum's recent 47 day expiry announcement.

To that end, we're beginning to look at support for ACME has an emerging protocol for certificate management automation. Our early assessment indicates this may be a good protocol for automating the management of certificates for which the gateway has the private key, and we're going to begin work on ACME support for that purpose in our next PI.

ACME does not appear to be a good solution for certificates in the gateway's trust store (for which the gateway normally does not have the private key), so we're considering other ideas for those. The trick may be finding a standards based mechanism (or otherwise) that is secure itself. For example, one idea would be to monitor URLs for certificate updates like we optionally do for other gateway assets like schemas, stylesheets, etc. However, that shifts trust off the gateway in ways that might be vulnerable.

It's possible that we won't find a perfect solution until ACME evolves or other standards emerge to address the new requirements. However, we may not wait for that ourselves, and instead we may offer a Layer7 solution that has trade offs and allow our customers to decide if they're comfortable with them.

Note, regarding gateway restarts when changing the default SSL key in regards to listener ports and HTTP route assertions per Gary's post, they are not required for listener ports but are required for HTTP route assertions. That said, it would be unusual for someone to use a gateway's default SSL key for mTLS in an HTTP route assertion. It's more likely that they would have one or more dedicated keys for that purpose.

Regards,

Ben Urbanski
Layer7 API Gateway Product Manager

[CHANGHYUK LEE]

Hello everyone,

 

Thank you all for your great interest and the numerous helpful responses. I sincerely appreciate the time you all took to contribute.

 

I wanted to clarify that while all the answers were insightful, Mr. Urbanski's response was the one that best addressed the core of my question.

 

My main goal was to understand the official support plan or the future direction for patches regarding the upcoming shorter certificate lifespans.

 

Thank you again to everyone for the valuable discussion.

 

Best regards,

[CHANGHYUK LEE]

@Vermeulen

Hello Vermeulen.

Thank you for pointing me to this new functionality. I wasn't aware of it.

 

It's great to learn that the Default SSL certificate can now be renewed without a gateway restart via the refreshOnKeyChanges parameter.

 

This was a huge help. I appreciate it.