I created CSR using my key pair. and I believe that CSR will only include my Public Key. and I sent the CSR to CA. and I got certificate from the CA.
When I look at certificate. I can see that it has serial number and some identity information.
Lets say, I create JWS(JSON Web Signature) of this serial number and identity information with my private key, and send it to CA.
How do they decrypt (or validate) it? (Because I don't believe that they have my private key.)
Oh.. I see, When I send JWS with my private key. I don't use that key for encryption. I use my private key to sign the message.
then CA will know that I signed by my private key. because they have public key. and Serial Number is not actually encrypted in JWS but signed by me.
The contents of JWS token are Base64 encoded and not encrypted
(remember encoding is different from encryption!).
Related
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 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.
Suppose we have two x509 certificates - client and server.
Is it possible to change some fields of client certificate (CN for example) and recalculate signature using server's public key (wich is known) in such a way that server will accept and successfuly verify client certificate?
In public key cryptography private key can encrypt and decrypt, public key encrypt only. So it seems that anyone who knows public key can recalculate signature and modify certificate?
Thanks.
In public key cryptography private key signs and decrypts and public key verifies and encrypts. You cannot perform both operation without having both keys.
Although, you are right that signing in case of RSA is essentially encryption with the private key, but since you don't posses private key you cannot re-sign certificate.
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.
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.