I received following files from another department in my company which I am supposed to install on my Tomcat 8.5 Webserver in order to activate HTTPS and use TLS/SSL:
csr.pem
ca.pem
intermediate.pem
certificate.crt
Most tutorials I found online guide through the process of creating the keystore, generating a CSR and installing the certificate received afterwards. My company wishes to use it's wildcard certificate, so the certificate and related files exist already.
I tried to generate a new keystore with my own private key & import ca, intermediate & certificate in it, but I'm getting an error which says that the public key doesn't match with my keystore.
I guess, this is because I need to import the private key used to generate the CSR before. But since I don't have it, I want to make sure - is it possible to install the certificate without the private key (respectively generating my own private key) or did they possible forget to send it along?
Wildcard or not, a certificate without its associated private key is useless.
As they are used in asymetrical cryptography, operations need the public key (contained in the certificate) and the private key (stored separately).
And they are generated together, you can not have a certificate and then later on generate a new key and associate with it. A CSR, which later becomes a certificate, includes some information derived from the private key.
Related
I received a wild card certificate from my customer. It contained three files:
something.crt
something.pem
gd_bundle-g2-g1.crt
The last one is a bundle of cert keys.
Previously, I always created my own private key to sign, but I do not know how to deal with this.
I use openssl and NginX on this site.
Is it possible to sign my own created key using this cert or should I ask for the private key which is the base of this cert?
Is it possible to sign my own created key using this cert ...
No
... or should I ask for the private key which is the base of this cert?
If you are supposed to setup a server with this certificate then you need the private key. It is unknown if the key is part of the send files since you only provide file names and the content of the actual files is unknown. Specifically it is unknown what something.pem contains or of something.* contains both certificate and key (which is possible with PEM format). But if the key is not there then you need to ask the customer for the key.
I was given a certificate from BaltimoreCyberTrustRoot but I wasn't given a key, Would I be able to generate a key for an existing certificate?
Obviously no you cannot generate a private key out of an existing certificate otherwise you would be able to impersonate basically any given HTTPS website (How? the certificate is public, you download it and magically create the associated private key and you have then a validated website for that certificate name...)
Normally generating a certificate works like this:
you generate a public/private key and the public key is used to compute a CSR or Certificate Signing Request which has the public key and some meta data
you give the CSR to the CA
the CA gives you back a certificate based on the content of the CSR, and signed by their own private key (so that by using the CA certificate - which has the corresponding CA public key - you can validate that this generated certificate was indeed signed/issued by this specific CA).
So you have the private key.
If you are on a case where the CA or the intermediate generates everything for you (which is bad security wise it means they have the private key and hence can impersonate YOU), then you have to ask them to send you both the certificate and the private key!
I'm new to setting up ssl for curl. We were given a .cer file and the admin created a private.key. When we tried to associate the .cer with the private.key, the modulus's don't match. Is there a way to correct this? it would be easier to recreate the private.key with the proper modulus but I'm unsure how to do this without wrecking the openssl configuration.
any assistance would be appreciated!
Tom
Something wrong with the process here. You can't be just 'given' a certificate and then create a private key for it. The process goes like this:
You create a private key.
You create a certificate signing request (CSR).
You submit the CSR to some certificate authority (CA).
They verify your identity and then issue you a signed certificate.
The CSR and the signed certificate both contain the public key corresponding to the private key you first created.
Can anybody clarify to me what kind of "Private Key" is located in a PFX file ?
I am asking this because after having read quite a lot on digital certification I am still a bit confuse on the Private Key part, especially when Certificate Authority is involved.
The part I am missing is where it is said that the Private Key is kept secret on the CA side but if I go in my Personal Certificate Store and I try to export a certificate, I am able to export it with the private key in it.
Is this private key is the same as THE private key that we are not supposed to know ?
Public key cryptography is used for two different purposes when it comes to X.509 certificates used for SSL/TLS.
Each X.509 certificate contains a public key, which has a matching private key held only by the identity this certificate belongs to (the subject of the certificate).
One of the purposes is to build trust in another certificate. A CA uses its private key to sign other certificates: possibly other (intermediate) CA certificates or End-Entity Certificates (the ones that are actually going to be used for the SSL/TLS connection itself).
For example, the Root CA's private key can be used to sign (i.e. issue) an Intermediate CA's certificate. The Intermediate CA certificate can be verified using the Root CA certificate's public key. The Intermediate CA's own key-pair isn't involved in this verification (although the verification process ensures that the public key in that cert belongs to the Intermediate CA).
The Intermediate CA's private key can be used to sign your server certificate (an EEC). The Intermediate CA's public key can be used to verify the authenticity of your server certificate. Someone who would only have the Root CA certificate can therefore check your server certificate by building a chain. Again, your server public and private keys are not involved in this verification at all, but the result of these operations proves that the public key in your server certificate belongs to your server name.
There is no relationship between any of the key pairs involved in a certification chain. Even the CA issuing a certificate will not (or should not) have access to the private key of the certificate it is issuing.
The second usage of public key cryptography is during the SSL/TLS handshake. The exact mechanism depends on the cipher suite, but this allows the client to agree with the server on a secret that only the server with the private key matching the public key in the server certificate will be able to see. It's this private key that is the private key of the certificate itself.
In a PKCS#12 file, you will find an End-Entity Certificate and the private key matching the public key in that certificate, to be used by the entity to which this certificate was issued, and generally a chain of CA certificates (from the one directly issuing the EEC to other CA certificate further up the chain, possibly up to a Root CA).
Here, I've taken this example of an EEC for an SSL/TLS server, but the same could apply for EEC to be used in other contexts (e.g SSL/TLS client or S/MIME).
If you are talking about SSL-Certificates and SSL I think you mean X509-Certificates in common. Let me make it clear first: the passwords of the private keys are different.
The magic here is Chaining of the Certificates, i.e.
Root Certificate from CA
Intermediate Certificate from CA (for instance Class 2)
Your Certificate
If you look at your SSL-Certificate, you will find this structure. Every certificate within this hierarchy can be seen as a certificate for its own. You can find more information within this msdn article. A briefly description from my point of view:
The Certifcates within this chain can be seen are separate Certificates. With their own ability to sign Information with the private key and validating signature with their private key. They are basically linked within this chain.
You might ask Why are the Certificates linked?
There are two main reasons: Security and Trust.
If you loose your private key or if your certificates is broken, it's need to be revocated. This basically says, that your Certificates should not be trusted anymore. It's listed on the Revocation-List on the parent Certificate to ensure that this security break can be fixed very fast. This behavior explains, why root certficates creating IntermediateCertificates and not your requested Certificate - they want to be sure that they can revocate their Intermediate Certificate as well.
Additionally to this functional explanation there is a mathematical, but I am not able to explain this is an easy way. You can find Information about this within it's article on Wikipedia. Basically it says, that you can't calculate the password from the parent and / or public certificate to use the private certificate.
I'm confused about something in the SSL renewal process using WHM/cPanel for an existing Comodo Extended Validation cert.
We have been issued a replacement certificate by Comodo without - I believe - every submitting a CSR for them. I say "I believe" because there are 3 people with access to WHM for this server, but I'm assured that no one has been fiddling in the last year.
Does this sound possible? CAN a cert be supplied without a CSR if it's a replacement? I will attempt to get hold of Comodo but being a weekend, and seeing that the old cert runs out in a day I thought I'd consult the stackHiveMind :)
More info:
As a test, I've tried to install the new cert and 'fetch' the existing private key, but when I try to submit that I get the following error:
SSL install aborted due to error: Modulus mismatch, key file does not match certificate. Please use the correct key file
In some cases, yes, you can. Assuming you have an RSA private key in PEM format, this will extract the public key (it won't generate a certificate):
openssl rsa -in key.pem -pubout -out pubkey.pem
This will create a new CSR with the public key, obtained from the private key file.
openssl req -new -key key.pem -out host.csr
Note that, strictly speaking, a CA doesn't need you to submit a CSR to issue a certificate. All it needs is the public key (to which it will have access through your existing cert). It could potentially attach any Subject DN and attribute and issue it as a certificate without any need to contact you. Of course such practices might be incompatible with their policies, but technically, it's possible. The CSR is merely a convenient format for you to send a public key to request a certificate, and submit the name and attributes you would like (which you all sign together).
SSL install aborted due to error: Modulus mismatch, key file does not
match certificate. Please use the correct key file
Provided you've done the certificate operations properly, this could indicate that the new certificate you've been issued has been issued against a different key-pair than yours. This could indicate foul play, because someone else could have issued a CSR with their own key-pair and have had this certificate issued to them (which could be quite worrying since you're talking of an EV cert too, which is supposed to have additional protections against this.)
I would suggest checking with your colleagues if any have requested a new certificate or contacting your CA to find out why you've received a new certificate. Renewing the certificate using the previous public key might be part of their existing package. If it's using the same public key, it's not a problem, although it's better practice to change the key material, i.e. submit a CSR coming from a new key-pair, when renewing a certificate.