I am trying out a scenario where mutual trust can be established between the client and server using kubernetes ingress controller.
We have two types of clients who would access our service deployed in k8s:
Internal systems/users
External systems/users
The idea is to build a certificate chain in the following way:
For internal systems/users, issue client certificates signed by Internal intermediate CA (Internal intermediate CA is signed by Root CA)
Root CA -> Internal intermediate CA -> internal client cert
For external systems/users, issue client certificates signed by External intermediate CA (External intermediate CA is signed by Internal intermediate CA)
Root CA -> Internal intermediate CA -> External intermediate CA -> external client cert
How can we accomplish mutual trust for the above scenario? Can we create a ca-cert secret with Root CA and the two intermediate CA certs and configure it in ingress for mutual trust.
Related
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs. On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
I know the truststore is to verify the 3rd party certificate during handshake
My question is what should my truststore actually store during handshake?
Youtube.pem (the CA signed certificate sent from 3rd part)
Google.crt (the CA certificate)
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs.
Yes, but you only need a keystore if you want to use client side authentication. Note that "keystore" and "truststore" indicate how the store is used, they can be of the same type (e.g. PKCS#12) and even the same file.
On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
No, YouTube is a service, it has a leaf or end-entity certificate. The root certificate is that of a third party CA. The end-entity certificate is usually signed by an intermediate CA certificate, and that is in turn signed by a self signed root certificate.
I know the truststore is to verify the 3rd party certificate during handshake
It is used to validate and verify the trust path from leaf certificate to a trust anchor in your truststore. The trust anchor is usually one of the root certificates stored in your truststore. The leaf certificate is indicated by the end entity / server, the intermediate certificates are usually sent by the server as well, but they could also be retrieved from a cache.
In the case of YouTube, the Google root CA is used, possibly using the GlobalSign root through a linked certificate if the Google root is not present in the trust store.
So your truststore should either contain the Google root certificate or the GlobalSign root for the connection to work in this example.
I am using OpenSSL program to generate my SSL self-signed certificate, created a CA certificate and a webserver certificate. The webserver certificate, I have signed it with the CA certificate. I created a keystore with Java's keytool to import webserver's certificate.
On the client side, I have imported the CA certificate inside client's Certificate Manager, under the "Trusted Root Certification Authorities".
In theory, is this way considered as a One way TLS or a Two way TLS communication?
Thank you so much for the help!
In TLS protocol by default the client validates servers authenticity, the server sends its certificate during the handshake and the client validates it with the CA certificate in its trust store. It is one way setup
For two way, during the handshake, the server also asks for certificate from client,it validates the certificate sent by the client with the CA certificate in its trust store. So if you want to use two way setup, you need to generate client CA certificate and client certificate(it will be signed by the client CA certificate), the same CA certificate you need to configure at server so that it(server) will be able to validate the client certificate it received during the handshake.
You can also decide to keep same CA certificate for both client and server certificates, making sure client and server certificates are signed by the same CA
When a TLS handshake takes place, the server sends in his ServerHello message, his digital certificate. This digital certificate is digitally signed by a intermediate CA named A and CA A also has a certificate which is signed by CA named root whose certificate is self signed, thus forming a certificate chain. The client then has to establish a trust, validating the server certificate. To perform that validation the client has to validate the entire chain correct?
Must the client have in a truststore all the certificates (A and Root) or the client will download them?
The client usually has only the root CA in the local trust store. The leaf certificate and the intermediate certificate leading to the root CA need to be provided by the server. The intermediate certificates are usually send in addition to the leaf certificate within the TLS handshake.
But it is a typical misconfiguration to only have the leaf certificate send by the server. In this case the certificate validation will fail unless the client has already knowledge of the intermediate certificates or can obtain these somehow. Since often the same intermediate certificates are used, some browsers like Firefox will cache the intermediate certificates they'll got when communicating with server A and fill these in when a broken server B is not sending the required intermediate certificates. Other browsers (like Google Chrome) will try to download the missing intermediate certificates from the internet. Most simpler clients (i.e. apps written in Python, Java ... or curl) will instead just fail with a certificate validation error.
I am new to kubernetes. here I have some confusions about the CA certificates used in a kubernetes cluster. As far as I know there are several CA certificates in kubernetes, but still not clear what each functionality of them. Here is my understanding of them, but still not sure of them.
Root CA also know as serving CA,
it signs the apiserver certwhich are configured in the apiserver with --tls-cert-file and --tls-private-key-file.
this CA certificate is configured in kube-controller-manager with --root-ca-file
Client CA
this CA certificate can be a intermediate CA certificate signed by ROOT CA certificate.
which is used to sign the individual components in cluster, help to identify their identities when RBAC and NODE authorization are enabled. for example, sign the kube-controller-manager, kube-scheduler, kube-proxy, kubelet.
can be configured in apiserver with --client-ca-file
requestheader client ca
this CA certificate can also be a intermediate CA certificate signed by ROOT CA certificate.
Still not understand what this CA is used for ? what scenario of the CA file, just found that if metric server is deployed, it will ask for requestheader related certificates and keys
for --proxy-client-cert-file and --proxy-client-key-file in kube-apiserver, what the value of these parameter? can kubelet certificates and keys be used?
Besides these CA certificates, some other certificates relative confusions are also encountered.
--service-account-key-file parameter in kube-apiserver and kube-controller-manager, which file can be configured? is the apiserver key file or ROOT CA key file ?
what can be set to
--cluster-signing-cert-file and --cluster-signing-key-file in kube-controller-manager? can we use client ca and client ca key file?
A good summary is at https://github.com/kubernetes/kubernetes/issues/54665#issuecomment-340960398
The request header CA is used to verify a client cert presented by an authenticating proxy along with user info set in request headers. The proxy authenticated the user, proxies the request, and sets username/groups in headers. The API server verifies the client cert before trusting user info in any headers.
We have an Azure web role deployed that uses HTTPS. We upload a certificate to azure and shortly after the portal refreshes and two more certificate appear. This is not a wild cart certificate and maybe this is standard behavior, but I haven't seen it before.
The original certificate is named something like:
subdomain.domain.com
The three certificates that appear are named like so:
VeriSign Class 3 Public Primary Certification Authority - G5
Class 3 Public Primary Certification Authority
VeriSign Class 3 International Server CA - G3
Are the 3 certificates I mentioned normally generated or is this an issue I should be looking into?
We have a similar deployment that has an ssl, but does not generate these extra certificates. This is what triggered our concern and has me asking why ...?
When you enabled HTTPS endpoint in any web application and bind SSL certificate to it, the certificate bind to HTTPS endpoint is could be a single certificate or it could be a chain and
it is depend on several factors as below:
When the certificate is created as self signed ROOT then it will have only one certificate in the chain. This certificate can not be validated to have SSL tunnel because there is no other part to verify it and that why it is called self signed root
When you buy certificate from a reputed CA (Certificate Authority) in almost all cases you will get 3 (or more) certificates:
2.1. Root Certificate : This certificate is helps to create a SSL tunnel between two machines using PKI security Infrastructure.
2.2. Intermediate Certificate -> This is to create a chain with multiple certs as if needed
2.3. Domain Certificate -> This is for your *.domainname.com or domainname.com
Here is an example of chained SSL certificate at https://mail.google.com
And all of these certificate are chained into one single PFX (if private key embedded into certs) or CER (without any Private Key) so when you deploy only ONE PFX cert, you see the chain is open and all certificates are listed.
If you browser your url and open the certificate view through browser, you will see exactly same chain as you could see in your portal and you can also verify the certificate thumbprint as well to match.