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.
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.
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 have read through this post on signing a PowerShell script with a certificate. This is more on using external certificate from VeriSign (or similar) to encode and protect the code I have developed within a PowerShell script.
I am just trying to find out if this will actually work. I would expect the process to go as:
Purchase code-signing certificate from VeriSign
Install certificate on my computer
Sign the PowerShell script
Execute the script on desired device
Since this script would be signed with a external CA wouldn't Windows be able to authenticate the certificate since Windows trust VeriSign root CA? My guess would be since Windows has the root CA for VeriSign already and trust it, if I happen on a system that does not allow Internet access that the certificate will still be verified and allow me to run it?
That should work. I've never tried it, though, but your logic makes sense.
I looked at the cert store on my Win7 machine and it has an Oracle code signing cert issued by "Verisign Class 3 Code Signing 2010 CA". That CA is an intermediate CA. The root CA is "Verisign Class 3 Public Primary Certification AUthority - G5". That root CA is in Windows trusted root CA store. So what I gather from this is:
That yes you can do it - Oracle does it
Verisign does issue code signing certs, but they are signed with an intermediate CA.
This means Windows has to obtain this cert somehow. The Verisign
intermediate cert does have the "Authority Info Access" field which
is one way Windows can retrieve an intermediate cert. But the
machine would have to be able to access the internet.
An alternative (if internet access isn't available) is to install the intermediate cert on your users' machines. Could be part of an installer. I think that must be what Oracle did on my machine
For an Authenticode EXE, another alternative (if machine can't access
internet) is to make sure intermediate cert was embedded in the
authenticode signature in the EXE. However I don't know if
Powershell would support that.
As another confirmation you could call/email Verisign to verify their support.
Executing the script on desired device still requires you to set the execution policy to at least AllSigned on that device. And you will still get a question if you want to trust this publisher, unless you add the certificate to the device or the domain. See here.