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.
Related
There are two separate CA virtual machines (Windows Server 2012):
RootCA
SubCA - created/signed by RootCA
RootCA is off and offline (no network connectivity).
How to renew Microsoft SubCA?
SubCA is valid for more than a year now, but we want to plan ahead.
Root and Sub CAs are not connected to Windows domain, it is not for used for Active Directory.
SubCA is used to generate SSL certificates for out internal servers - Apache, Nginx, IIS, etc.
RootCA and SubCA certificates are trusted on Windows and Linux machines (both servers and workstations).
Is it necessary to add newly renewed SubCA certificate as trusted after renewinig it? Or it will be already trusted, but now it is just renewed?
The renewed SubCA will be trusted as it will be signed by the already trusted RootCA - that's how PKI works.
Never add the new SubCA certificate into your trust-store as it mustn't be explicitly trusted. It is only implicitly trusted because it's issuing CA (the Root in this case) is trusted. Remember that if you were to add it to the trust-store and you subsequently decided that the SubCA was compromised and therefore required revoking, you would have to manually remove it from all trust-stores - a laborious process.
Instead, you will need to give all subscribers this new SubCA certificate when you next renew their end-entity certificate so that they present the correct chain when relying parties connect (as required by the TLS protocol).
In the Windows world you can add it to the Intermediate CA store (not the Root CA store remember!) so that servers have it to hand when their end-entity certificate is renewed by the Sub CA. Windows will figure out which CA certificate to send when the end-entity certificate is renewed.
In the non-Windows world you have to read the documentation for the application to ascertain where the CA certificates should be installed. Quite often, they are appended to the file containing the end-entity certificate, but it can vary - so do check.
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.
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/
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.
can any one tell me how to verify the P7b container (which have three different files )against the CA Certificates available in "/home/user/Certificate/" folder(includes the intermediate certificates) using openssl.
i have 5 different Root certificates and each have 3 intermediate Certificates.