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.
Related
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!).
I know this is probably a bad question but I am so confused. I have a tls certificate and a tls key file, tls.crt and tls.key. I think I'm supposed to convert them into a public and private key, relatively, in order to use openssl.
side note: Am I approaching this wrong? Is there some TLS application to encrypt/decrypt?
To convert the public key, I use
$ openssl x509 -pubkey tls.crt -noout > pubkey
This created a public key that I was able to encrypt a message file with by doing
$ opensssl rsautl -encrypt -inkey pubkey -pubin -in <message file> -out <encrypted output>
I have successfully encrypted the file but now I don't know how to decrypt it. I don't know how to convert my private key (tls.key) into an ssl private key. This is what stumps me. Shouldn't I be doing some tls encryption/decryption? If not, and I am supposed to be using openssl, how should I convert tls.key into a private key usable by openssl rsautl -decrypt?
tl;dr: The key file is the key file you want. No conversion should be required.
The trick here is in the following question: "What is a certificate?" The answer is that it is a signed public key that goes along with a secure private key. It (usually) gets signed by a CA ("Certificatation Authority").
The basic process is:
Entity that wants a certificate creates a private/public key pair.
Entity send the public key and some information about the Entity to the CA.
The CA performs "some level" of validation on the Entity, verifying their identity. Usually this is just some level of proof that the requestor owns the web site the certificate is to be used for.
The CA takes the provided public key and the other info provided, uses their private key to generate a signature for that data, which then can be verified by decrypting the signature using the CA's public key. That becomes your certificate.
So, you took your own public key from the certificate. The private key (tls.key) should be the key file you created in the first step - just use it on your encrypted data.
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!
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.