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!
Related
I have done some research on this but still have some trouble connecting the dots as to what exactly happens when the server send its certificate to the client in terms of verifying signature and root certificates.
When you create a CSR, it generates a private key along with it, and you send it to the CA to generate the cert and sign it, but doesn't the CA use it's own private key to sign? So what is the point of the private key you generated with your CSR?
When server sends its certificate for client to validate, how exactly does client validate that it is a valid CA cert. It has a collection of trusted CA certs, ok - but how exactly are they used to verify that it was a valid CA that signed the server's certificate using the signature and public key of the server certificate? What things are compared to make sure it was not forged?
Is there any point in encrypting your internal self signed certs? How about an internal root cert? Or is the private key the only one worth encrypting?
If we don't keep a database of encrypted data for our web service (over SSL) for example, would we ever care about storing our own private key once we generated the self signed cert, and if we do, they why?
When you create a CSR, it generates a private key along with it
Or you have already generated your own private key.
and you send it to the CA to generate the cert and sign it
You send the CSR. You don't send your private key. It's private. You don't send it to anyone.
but doesn't the CA use it's own private key to sign?
Yes.
So what is the point of the private key you generated with your CSR?
It pairs with the public key contained in the certificate and it is part of the process used to prove that you and only you own that certificate, as only you can generate digital signatures with that private key that can be verified by the public key in the certificate.
When server sends its certificate for client to validate, how exactly does client validate that it is a valid CA cert. It has a collection of trusted CA certs, ok - but how exactly are they used to verify that it was a valid CA that signed the server's certificate using the signature and public key of the server certificate? What things are compared to make sure it was not forged?
The certificate itself is verified, by verifying its digital signature; it is checked for being within its validity period; and then an attempt is made to form a certificate chain using the alleged signer of the certificate (the 'issuer') and the trusted certificates in the collection.
Is there any point in encrypting your internal self signed certs?
No. They are public documents. Only the private key is private, and that isn't in the certificate.
How about an internal root cert?
No.
Or is the private key the only one worth encrypting?
Yes.
If we don't keep a database of encrypted data for our web service (over SSL) for example, would we ever care about storing our own private key once we generated the self signed cert, and if we do, they why?
Because it's private. It is a critical part of your identity. If you leak it, others can impersonate you.
Amazon Cloudfront is giving me errors, either my private key doesn't match my public key certificate or my public key certificate cannot be parsed as it's invalid.
Using Godaddy for my SSL certificate middle man/provider, I got a:
.pem whoose contents beings with "-----BEGIN RSA PRIVATE KEY-----"
(I'm assuming that's my private key)
Inside Godaddy I am able to download some certs for the SSL, they are:
.crt (type = Security Certificate)
.p7b (type = PKCS #7 Certificate)
Is one of the above my public key? Or is there another way I am supposed to get my public key?
I have encountered this issue before with bad CSR Request.
According to GoDaddy:
To install a digital certificate, you must first generate and submit a Certificate Signing Request (CSR) to the Certification Authority (CA). The CSR contains your certificate-application information, including your public key. Use your Web server software to generate the CSR, which will also create your public/private key pair used for encrypting and decrypting secure transactions.
http://support.godaddy.com/help/article/5343/generating-a-certificate-signing-request
It also states: NOTE: When generating your CSR, specify a key size of 2048 or higher.
The key size is sometimes the culprit. Hope it helps.
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.
As I understand, the root of SSL security is based on the public key of certificate authority. And I don't know why this key can be faked by a man in the middle:
The man in the middle received this CA public key but then sends me a public key and fake certificate of his own and pretends that it is valid. I use this key to compute the certificate signature to verify it but if this key is fake, how can I know certificate is not from a trusted source?
In order for any PKI to work, each party should have a list of public keys for CA they trust. These keys have been obtained out of band, securely, from a software vendor.
The SSL certificate (containing the SSL server's public key) received from the server is signed by the private key of one of AC. There is no way to forge a valid certificate without access to one of the CA's private key, so the man in the middle can not send a forged one that will look valid.
The is two things that we need trust in order to use PKI :
1/ that we can securely retrieve the CA's public keys
2/ that the CA won't mess up by signing forged certificates or by getting their keys stolen.
Need the understanding about SSL and the way it functions. Kindly help answer the below.
I understand that the CSR that we generate has our public key and DN info i.e C=,CN=,L=,O=,OU=,ST=.
Are both these two compoments (JPMC public key and the DN) hashed and if the hash is also send to verisign at the time we request them for a cert (new cert or a cert renewal).
What amount these (public key, DN and the hash) are encrypted using JPMC's private key.
Does Verisign (CA) use the public key that we send them as part of the CSR or do they have it from other means inorder to decrypt whatever was encrypted above.
No, the information in a certificate signing request is not hashed - how could it be - you can't get the information back after hashing? It is not encrypted either, none of the information is sensitive.
A CSR contains the version of the PKCS#10 standard which is being used, the DN of the entity the certificate is for, the public key that will be used, and optionally, some attributes such as subject alternate names, etc.
The CSR is signed, using the private key generated to initiate the request (or, in renewal, the private key of the existing certificate).
PKCS#10 is the main specification for all of this.