When you wish to have a well-recognized cert, but don't wish to publish the resource on the public internet to serve ACME challenges
When you wish to use an extended validation certificate
Because you want to, dangit
In those situations, we need a pattern to inject the certificate and key. This will need two patterns to account for the different contexts in which it might be used. In all cases (because it's how Nginx works, we'll have to trust the security of the Nginx container and filesystem to store the SSL key, however, we may have different levels of trust for the service discovery layer:
The service catalog is being used for application discovery (not infrastructure discovery), and access is limited to trusted application operators, and therefore is a trustworthy store for secrets
The service catalog is, for one reason or another, not trusted (though, remember, that anybody with access to the Nginx instances will have access to the certificate and key), so a different store, perhaps Vault, will be used for the secrets
This ticket will stand for developing the first pattern. A new ticket shall be opened for the eventual development of the second pattern.
https://github.com/autopilotpattern/nginx/pull/30 implemented Let's Encrypt support for east and automatic SSL encryption, but there are times when a traditional SSL cert is more desirable:
In those situations, we need a pattern to inject the certificate and key. This will need two patterns to account for the different contexts in which it might be used. In all cases (because it's how Nginx works, we'll have to trust the security of the Nginx container and filesystem to store the SSL key, however, we may have different levels of trust for the service discovery layer:
This ticket will stand for developing the first pattern. A new ticket shall be opened for the eventual development of the second pattern.