As far as I read all the SSL certificates are signed using public key of the asymmetric pub/priv key pair.
But all (atleast what I checked) the examples out there on internet are using private key
One way I found for self-signing is using below command:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
Other way I found is:
sudo openssl genrsa -out mykey.key 2048
sudo openssl req -new -key mykey.key -out mycsr.csr
sudo openssl x509 -req -days 365 -in mycsr.csr -signkey mykey.key -out mycert.crt
Are the above examples using public key to create the certificate or private key. If private key, is it a right usage?
One more thing,
What is the difference from self-signing vs CA signing the certificate.
Is there any additional information of the signing authority present in the certificate?
And what does CA signing actually mean?
Do they use their own private keys to sign or what is it all about?
EDIT:
The above statement As far as I read is from point#2 of the following website.
I could be completely wrong in understanding its statement since I'm very new to SSL concepts
http://tldp.org/HOWTO/SSL-Certificates-HOWTO/x64.html
If private key is used for signing the certificate and also the same private key is used in apache http server configuration I'm still confused from where will the browser get the public key in its initial SSL handshake
I'm referring to the following configuration of apache httpd
<VirtualHost 192.168.0.1:443>
DocumentRoot /var/www/html2
ServerName www.yourdomain.com
SSLEngine on
SSLCertificateFile /path/to/your_domain_name.crt
SSLCertificateKeyFile /path/to/your_private.key
SSLCertificateChainFile /path/to/DigiCertCA.crt
</VirtualHost>
UPDATE:
I'm specially pointing to the section 1.2.2 of the above link where it states
This someone, you have to implicitly trust: you have his/her certificate loaded in your browser (a root Certificate). A certificate, contains information about the owner of the certificate, like e-mail address, owner's name, certificate usage, duration of validity, resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage) and the certificate ID of the person who certifies (signs) this information. It contains also the public key and finally a hash to ensure that the certificate has not been tampered with.
Why SSL certificates are signed with the private key?
Because that's how digital signatures are defined. Signing it with the public key wouldn't prove anything. A digital signature has to be something that only the signer can do, just like your signature on a cheque only harder to forge. Much harder.
As far as I read all the SSL certificates are signed using public key of the asymmetric pub/priv key pair.
No you didn't, you misunderstood what you were reading.
But all (atleast what I checked) the examples out there on internet are using private key
Of course.
Are the above examples using public key to create the certificate or private key. If private key, is it a right usage?
They are using both. The public key is embedded in the certificate and the private key is used to sign it.
What is the difference from self-signing vs CA signing the certificate.
Is there any additional information of the signing authority present in the certificate?
Yes, there is an IssuerDN field.
And what does CA signing actually mean? Do they use their own private keys to sign?
Yes.
The above statement As far as I read is from point#2 of the following website.
No it isn't.
I could be completely wrong
Yep.
If private key is used for signing the certificate and also the same private key is used in apache http server configuration I'm still confused from where will the browser get the public key in its initial SSL handshake
From the certificate.
I'm specially pointing to the section 1.2.2 of the above link where it states
[snip] It contains also the public key and finally a hash to ensure that the certificate has not been tampered with.
There is nothing there about signing the certificate with the public key. 'Contains' does not mean 'signed with'.
Related
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'm having problems understanding the difference between files produced by openssl and how to detect them.
For example I'm trying to generate Self-signed cert with private key and generate JKS file from p12
format. I'm googling like a madman but I still don't know how to generate it correctly to be able to use following commands.
openssl pkcs12 -export -in user.pem -inkey user.key -certfile user.pem -out testkeystore.p12
keytool -importkeystore -srckeystore testkeystore.p12 -srcstoretype pkcs12 -destkeystore wso2carbon.jks -deststoretype JKS
Source: https://www.ibm.com/support/pages/how-generate-jks-keystore-existing-private-key
I found a couple of different commands to generate Self-signed cert and private key but I don't know how to map resulting files to the commands above and whats worse I don't understand what those commands do.
I mean I see what files they generate and understand that certificate and private key used to sign it ( or maybe the other way around :| ) but what is the difference between those commands and is cert.pem === certificate.crt - Those file extensions are driving me crazy.
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
This is yet another situation where I'm having similar issues with the openssl command. At this point I'm even ready to read some RFC ( I hope it won't come to this :) )
Thanks in advance for help
Those file names represent different parts of the key generation and verification process. Please note that the names are just convention, you could just as easily call the files pepperoni.pizza and the content will be the same, so do be conscious of how you use the filenames.
A brief primer on PKI - Keys come in two halves, a public key and a private key. The public key can be distributed publicly and widely, and you can use it to verify, but not replicate, information generated using the private key. The private key must be kept secret.
.key files are generally the private key, used by the server to encrypt and package data for verification by clients.
.pem files are generally the public key, used by the client to verify and decrypt data sent by servers. PEM files could also be encoded private keys, so check the content if you're not sure.
.p12 files have both halves of the key embedded, so that administrators can easily manage halves of keys.
.cert or .crt files are the signed certificates -- basically the "magic" that allows certain sites to be marked as trustworthy by a third party.
.csr is a certificate signing request, a challenge used by a trusted third party to verify the ownership of a keypair without having direct access to the private key (this is what allows end users, who have no direct knowledge of your website, confident that the certificate is valid). In the self-signed scenario you will use the certificate signing request with your own private key to verify your private key (thus self-signed). Depending on your specific application, this might not be needed. (needed for web servers or RPC servers, but not much else).
A JKS keystore is a native file format for Java to store and manage some or all of the components above, and keep a database of related capabilities that are allowed or rejected for each key.
The commands you list look fine to me, and I don't see a question beyond asking what the different files are for. If you need more information, please enrich your question.
.key is the private key. This is accessible the key owner and no one else.
.csr is the certificate request. This is a request for a certificate authority to sign the key. (The key itself is not included.)
.crt is the certificate produced by the certificate authority that verifies the authenticity of the key. (The key itself is not included.) This is given to other parties, e.g. HTTPS client.
.pem is a text-based container using base-64 encoding. It could be any of the above files.
-----BEGIN EXAMPLE-----
...
-----END EXAMPLE-----
.p12 is a PKCS12 file, which is a container format usually used to combine the private key and certificate.
There isn't only one extension. For example you may see certificates with either the .crt or a .pem extension.
Just to add more info: .der, another (binary) encoding (either public or private key, or csr)
We need to provide a secure SSL on our intranet website. Could anyone please help me query below:
Is it possible to get Internal CA signed cert without a CSR?
If above is Yes, how do it generate a Internal CA signed Cert without a CSR.
What am I trying to achieve?
We don't have Production IIS setup. And production IIS will only be setup during the change window. During this change window no resource available to generate CA signed Cert. for a given CSR. Hence, we are trying to create CA signed certs before hand without having to setup the Prod IIS.
The Certificate Signing Request (CSR) is a tool for including a third party in the certificate creation process without divulging your private key. Its essentially a packet of encoded information (including the public key) which can be sent to the third party for signing. The third party receives the CSR, signs it with their intermediate or root certificate, and send back the certificate to you. Your new and shiny certificate file is now a keypair with your private key file. Even better, the third party never had access to your private key through the entire process.
Now to answer your question, yes it is possible. There is no requirement that a third party be involved. Its more a question of how to accomplish this with the cryptographic library of your choice. Check out my post here for a way to get OpenSSL running on windows without admin privileges.
Create a new key and certificate
openssl req -newkey rsa:2048 -nodes -keyout [filepath to key] -x509 -out [filepath to cert]
Create a certificate from an existing key
openssl req -key [filepath to key] -x509 -out [filepath to cert]
You should be able to use OpenSSL to create a CSR independently of IIS (see its req command).
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.
I am in the process of purchasing a Thawte SSL cert to be applied to my slice on slicehost which is hosting my new web app.
Thawte is looking for a CSR.
How do i generate this?
Regards,
Fiona
I doubt you still need this info after 9 months, however...
You'll need to generate an OpenSSL keypair and a Certificate Signing Request.
The keypair consists of two cryptographic keys. A public and private. The public key is included with the CSR along with other applicant information such as name, company, etc. The private key is used to sign the CSR request.
A CSR is what you send to your chosen Certificate Authority (CA) to request that they supply you with an SSL certificate. It includes your identifying information and the public key for your server/site.
Generate the CSR
openssl req -new -newkey rsa:1024 -nodes -keyout example.key -out example.csr
You’ll be prompted to enter information such as Common Name, Organisation, Country etc.
It should be fairly straight forward, but your CA will let you know if you’ve done it wrong, I’m sure.
This will create example.key (the private key) and example.csr (the CSR).
Requesting your certificate
Normally your CA will have a form on their website which allows you to paste in your CSR. This obviously varies from company to company. Once you have given them your CSR, they will first ask you for money, and then generate your CRT file.
P.S. I basically copy and pasted this info from my website, dunno if that's allowed here.