I have 2 Private CAs at the moment, one Root CA and a Subordinate CA. The Subordinate CA's CSR is signed by the Root CA. We have apps that would be using the Subordinate CA to do mutual TLS authentication.
Question: I have existing certificates that have been signed by the Root CA, can that be used in conjunction with the Subordinate CA? Or do I have to create new certificates that are signed by the Subordinate CA in order for it to work?
The certificates signed by the root CA are trusted. It is the nature of PKI. If you place RootCA's certificated into CA store, then all certificates signed by that certifcate will be valid. Still ...
Typically it is considered unwise to sign end-users certificates with the root. It is a long-lasting certificate that serves as the cornerstone of the whole infrastructure. In your place I would consider unifying PKI and re-issue the end-users' and servers' certificates using the intermediate CA.
Related
We have a Windows 2019 DC - ADCS PKI. It consists of A Root CA and a Subordinate CA. When the subordinate CA issues a certificate, the Root CA is not present in the chain. If you open the issued certificate and go to the "Certificate Path" tab, the Subordinate CA Certificate is the highest in the chain. If you click on it, it shows "The issuer of this certificate could not be found." as certificate status.
Now I have 2 questions.
What can I change in my PKI configuration so that the Root CA will always be present in new issued certificates. (I assume it is due to a misconfiguration).
Can I add the Root CA into an already issued certificate?
I thin you're misunderstanding the role of the Root CA certificate here as well as the concept of the certificate chain.
When your subordinate CA issues a certificate to an end-entity (such as IIS, for example) the only connection the issued certificate has with the subordinate CA is that the name of the CA is embedded within the certificate (the Issuer field) and that this certificate is signed by the CA's private key with this signature also embedded as part of the certificate. The CA certificate is not attached to your certificate in any other way.
When you double-click on the certificate in Windows, it shows you details of that certificate. When you look at the Certificate Path tab, it simply shows you as much of the chain as it can work out. It will look at the issuer of your certificate and if it has access to the Sub CA certificate from it's certificate store or by downloading it from the repository, it will list it too. That CA certificate also has an issuer (the Root CA in your case) and if it has access to that within its certificate store, it will also list it in the Certificate Path.
The Root CA is installed in a specific certificate store called the trust-anchor store. This is where you (or your admins) install root certificates that you have verified and have decided to trust. These are used to build certificate chains. That is, if your certificate chains to a root CA certificate in this trust-anchor store, then you are implicitly trusting your certificate. If a certificate doesn't chain to a root CA certificate in your trust-anchor store, then you don't trust that certificate. It is this latter which you're seeing at the moment. That is, you haven't installed the root CA certificate in your trust-anchor store.
In Windows, the trust-anchor store is shown as a subfolder of your Certificates MMC called Trusted Root Certification Authorities.
You can manually import your root CA into this trust-anchor store (right-click, All Tasks > Import..., or you can use Active Directory or Group Policy to distribute them to all or some computers.
Once you have your root CA installed in your trust-anchor store, you should be able to view the whole chain and won't get the The issuer of this certificate could not be found. message.
Does setting ssl.client.auth=required mean that the client's certificate has to be added to the kafka truststore?
Regards,
Yash
Setting ssl.client.auth=required means that clients will need to pass SSL/TLS client authentication which is based on the truststore.
The truststore should contain certificates of trusted certification authorities. So if your clients use signed certificates, you should put the certificate of this certification authority into the truststore. That would allow all clients who have a certificate signed with this CA to authenticate.
If you use self-signed certificates or if you want only selected signed certificates to authenticate, you can put directly their certificates into the truststore. But they will be treated as trusted CAs - so if the client uses its client certificate as a CA and sign more certificates, these will be also able to authenticate. So this is not completely secure.
When I use self-sign certificate, I made a self-CA.cer and a server.cer, server.cer is for web service and self-CA.cer is added in client code. When I check certificate , I check if server.cer is from this self-CA.cer, right?
But, if I buy a CA certificate, what I only got is a server.cer generated from CA, right? and CA certificate can generate many server.cer, and they are all trusted , what I got is one from these .
In my client code, others said I only need to change my http to https, that's it ,after I buy CA. but how can I distinguish which server certificate is from my own server? I only want trust the server certificate from my own server.
if I buy a CA certificate
you can't buy a CA certificate (with small exception, which is not your case). You are purchasing an end-entity certificate which cannot be used to sign other certificates. It is controlled by a Basic Constraints certificate. Any standard validation code will reject any certificate that is signed by non-CA certificate due to Basic Constraints extension value (isCA attribute is set to False).
RFC 5280 -- Basic Constraints
If you trust a CA you trust all certs they issue (unless expired or revoked) -- that's how PKI works.
If that CA issues certs to other sites/servers, and you make HTTPS (or otherwise SSL/TLS or DTLS) connections to those other sites/severs, you will trust their certs and thus trust them.
But if you mean you want to trust only the specific cert issued to your server for your server, that's automatic. The cert issued to your server has your domain name in it, while the certs issued to other servers have their (different) names, and an HTTPS client like a browser will only trust a cert that is issued by a trusted CA and has the correct server name in it, so it will trust only your cert for your server, and will trust other certs only for the other servers those certs are issued to.
For much more detail, see Stack's Great Ursine Epic https://security.stackexchange.com/questions/20803/how-does-ssl-work/
Let's say we have a server only running REST API services, only on HTTPS.
The only consumer of the APIs is a mobile app.
Do we need certificate from CA or a self signed certificate is enough?
You will need to use a CA certificate. Otherwise, each mobile client will have to manually set your certificate as trusted.
You can potentially embed the certificate as trusted in the mobile app itself (assuming you distribute the app), however it will be a problem when the time comes to renew the certificate, or rekey/replace the certificate for whatever issue.
Using a globally trusted certificate is the way to go.
You can :
Keep a self-signed certificate, but then you have to pin the certificate, and you can't revoke it if the private key is compromised.
Use a home made certificate authorities, but then you have to pin the certificate, and manage the revocation process (maintain an OCSP or CRL).
Use a certificate from a trusted CA, revocation will be checked for you, and if you want additional security, you still can pin the certificate.
In my opinion, the use of a trusted CA is more secure and more simple.
I'm not clear about the authorization of certificate: a website has been associated with a certificate, say https://test.mysite.com. Do I have to install the certificate on my computer before access this url?
Another question is: every certificate is issued by a CA. If I have trusted a CA before by "installing" a cerficiate, will I trust the all the following certificates issued by the same CA?
Thanks!
It depends on the library or browser you are using to access to the URL but, if the certificate is issued by a trusted CA (one that your library or browser already trusts), the web site's certificate does not need to be installed before accessing the site.
If the CA is not trusted, there are two options. One is to trust the certificate. Browsing to the page will usually open a dialog where the user can choose to trust the certificate, for example. The second is to add the CA to the list of trusted CAs. On Windows, this is done by adding the CA's certificate to the "Trusted Root Authorities" certificate store. The latter case means any other certificate issued by the CA will also be trusted.