I am trying to create a TLS secret for our key-cert pair that is issued by Entrust (third party CA) .
The cert has an intermediate CA and a root CA . This documentation has instructions on how to create a TLS secret - but I do not see instructions on how this can be done when we have a root/intermediate CA .
Any inputs would be appreciated.
you can use cert-manager. they can help you to create secret of crt and key with your root ca. you can check there documentation.
install cert-manager
details
Related
As a part of the POC, I followed the article https://www.ais.com/how-to-configure-point-to-site-vpn-connection-using-azure-certificate-authentication/ and configured Point-to-Site.
In summary: I have created the Root & Client Certificate and configured the Virtual Gateway
Here we are generating the root certificate
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature -Subject "CN=VPNRoot" -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign
Here we are generating the client certificate from the root certificate
New-SelfSignedCertificate -Type Custom -DnsName VPNCert -KeySpec Signature -Subject "CN=VPNCert" -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My" -Signer $cert -TextExtension #("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
Now that it works, my goal is to replace the certificates ("Root" and "Client") with production ready certificates.
From the Certificate Authority, what kind of certificates should be requested?
Note: Our Azure Tenant is something like xyznp.onmicrosoft.com
Note that In Azure Point to Site, you can use a root certificate that was generated using an Enterprise solution, or you can generate a self-signed certificate.
Refer : About Azure Point-to-Site VPN connections - Azure VPN Gateway
When you are using the enterprise solution certificate chain in the root certificate, you should acquire the .cer file for the root certificate that want to use.
And generate a client certificate with the common name value format name#yourdomain.com. In your case it should be in the format xyznp#onmicrosoft.com
Refer : Connect to a VNet using P2S VPN & certificate authentication: portal - Azure VPN Gateway
NOTE : Verify the authentication order on the client certificate if you used a certificate that was issued by an Enterprise CA solution and but having trouble for authenticating.
By double-clicking the client certificate, choosing the Details tab, and then selecting Enhanced Key Usage, you can verify the authentication list order like below.
Make sure Client Authentication is listed first. If it isn't, create a client certificate based on the user template with Client Authentication listed as the first item.
Refer: Connect to a VNet using P2S VPN & certificate authentication: portal - Azure VPN Gateway
I am trying to use my own CAs on k8s for internal https communication.
I read the documentation Certificate Management with kubeadm where I use on my conf file the paths as described:
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
controllerManager:
extraArgs:
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
When I launch the master prime node I get the following error:
error execution phase certs/apiserver: couldn't load CA certificate ca: ca certificate is not a certificate authority
I tried to find a way to define the authority and I found this Certificates. I do think that this is what I am looking for as this is referring to how to produce your own self signed CAs.
The CAs that I want to apply are from an official authority.
Is there something that I am missing here and I can not figure out?
I am running on 1.19.2 version
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T13:41:02Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T13:32:58Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}
You have got a private key and server certificate signed by an external CA with it's private key. You really do not have the CA's private key itself.
If you were using the self signed CA option then you actually got the private key of CA with you and kubeadm could use that to sign and generate all the server and client certificates for the control plane components.
You need to follow the External CA mode of kubeadm where in you just provide the ca.crt in /etc/kubernetes/pki/ca.crt location.
This will make use of the server certificate to host Kubernetes API Server over https which is what you are trying to achieve.
Please note the following
In this case you will not be able to use kubernetes to issue certificate by approving certificate signing request because you do not have the private key of the CA to sign a CSR.
Since kubeadm is running in external CA mode; all the certificates for the control plane components must be provided by the user, because kubeadm cannot generate them by itself.
I'd like to build my own self-signed CA structure to use in my applications. The idea is presented by the following picture:
So, to summarize it, I want a CA that has several levels of intermediate certificates.
For instance I want to create a Root CA that signs all of my apps and then create an intermediate cert for my first app APP_1. This app is used by several companies so I want that every company has it's own intermediate cert just for them which is signed by APP_1 (you can imagine this intermediate cert as a "child" of APP_1 cert). Company intermediate cert then signs end-user's certificate which he uses on his device.
Is it possible to create this cert hierarchy scheme with OpenSSL?
I've tried to create an example of this scheme and it went well until I tried to verify Company_1 intermediate cert. The verification with the chain was successful, but the verification with the intermediate cert that created this one failed. The command that fails is this one:
openssl verify -CAfile /CA/app_1/certs/app_1.cert.pem /CA/app_1/company_1/certs/company_1.cert.pem
The error is as it follows:
error 2 at 1 depth lookup: unable to get issuer certificate
error /CA/app_1/company_1/certs/company_1.cert.pem: verification failed
What am I doing wrong? Should I also verify the Company_1 intermediate with Root CA as I do with APP_1?
openssl verify by default wants to build the full chain. But you only provide the leaf certificate and the chain certificate and not the root certificate (which is signed by itself). To accept a chain certificate as the final trust anchor instead of a root certificate use the -partial_chain option:
$ openssl verify -partial_chain -CAfile app_1.cert.pem company_1.cert.pem
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.
I'm trying to setup client certificate authentication using haproxy.
With openssl I have created a CA and an intermediate CA. I want to allow only client certs signed by this intermediate CA.
What should I provide in the ca-file option : intermediate CA cert or should I provide concatenation of cert + key ?
When using cert or cert chain (cat CA + intermediate) I get the following error : ERR_BAD_SSL_CLIENT_AUTH_CERT and the browser doesn't ask me for a cert.
here is the haproxy bind config :
bind *:443 ssl crt /etc/ssl/private ca-file /etc/haproxy/ca-chain.cert.pem verify required crt-ignore-err all
Thanks for your help,
Jonathan