Thanks @SvenWal . your blog post gives answer of many questions. However, I still feel there is need of more detailed documentation.
I tried to understand your post and made below conclusion. Please correct if necessary.
I also made few comments on your topics.
For topic #1 Certificate presented by Kong to the client - Certificate Per Route :
Apart from SNI, we can utilize SAN (Subject Alternate Name) feature of the SSL certificate. Here, Kong’s cert will be only one though there are more than one hostnames of the kong. Just need to add all hostnames in the certificates SAN section.
As per my understanding, ssl_cert and ssl_cert_key are the kong gateway’s ssl cert and key.
For top #3 Certificate presented by Kong to the upstream:
- As per my understanding client_ssl_cert and client_ssl_key mentioned here are the Kong gateway’s certficates. These can be the same as mentioned above (ssl_cert and ssl_cert_key)
For topic #3 Certificate presented by Kong to the upstream - Certificate per service
- If ssl_Cert and ssl_cert_key are the kong’s certs then there is no chance to have different certificates to be presented to the upstream. The upstream should hold only one gateway’s cert as gateway is the client app and upstream is the server.
Apart from the above points, here is what I summarize. Here we are not bothering about how and where client and upstream systems are installing certs. Only concern is Kong
client app<–>Kong<–> upsteam
For client app <–> kong communication, kong will share it’s public cert (mentioned in ssl_cert) to client app to install this in client’s trustore. Kong will install client app’s ssl cert in kong’s truststore (using ca_certificates API endpoint)
For kong <–> upstream communication, kong will share it’s public cert (mentioned in client_sll_cert or ssl_cert) to the upstream app to install this in upstream’s truststore. Upstream will provide it’s public cert to kong and kong will install this using ca_certificates admin api.
Please correct if above understanding is wrong w.r.t. Kong.