I have a question about TLS/SSL (self-signed certificates)
I am trying to open a connection using several tools (ncat, socat) by using TLS/SSL.
Of course first i need to generate certificate. (Key is a KEY, and Cert is a CERT, PEM is an encoded format). I have found 2 different ways.
1) openssl req -new -x509 -keyout test-key.pem -out test-cert.pem.
2) openssl req -newkey rsa:2848 -nodes -keyout test.key -x589 -out test-cert.crt
cat test-key.key test-cert.crt > test-pem.pem
My questions:
Why at the end of the day we combine CERT with KEY? Should not CERT already have KEY inside?
Why on most tutorials, we send(by listener on socat/ncat) key with cert, if cert already have a key?
(Assume we do not verify cert)
Thanks for support.
SOLVED.
Should not CERT already have KEY inside?
The certificate has the public key inside. The key file is the private key. The public key can be visible to others (as does the rest of the certificate), the private key should be kept secret.
Related
I am trying to generate self signed certificate. I notice that there are 2 ways of doing it.
The first way
generate a CA Cert
On the server
generate server private key
use server private key to generate a cert generation request
use cert gen request and CA Cert to generate server cert
The other way does not involve the CA Cert
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout server.key -out server.crt
Just this line will generate both server cert and server private key.
May I know what is the different between this 2 ways of generate the server cert and key?
i am trying to create a self signed certificate using openssl following the docs https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https-ssl.html
i tried to add the generated private and public pem files to my NLB TCP listener as a self signed certificate and it is failing with the below exception.
Error creating listener The imported certificate's configuration is not compatible and will not appear in the list of available certificates for your listeners. Select or upload a different certificate and try again.
I saw that NLB allows RSA 2048 certs. Not sure why the console is showing the error display.
You need to generate a RSA 1024 or 2028 certificate. check the valid certificates that ACM supports. i used the below commands to generate the self signed certificate
openssl genrsa -out private-key.pem 1024
openssl rsa -in private-key.pem -pubout -out public-key.pem
openssl req -new -x509 -key private-key.pem -out cert.pem -days 3600
mention the country, state and domain name. I initially missed the domain name because of which NLB listener wasn't accepting the certificate.
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)
I have read an article on how to create a local SSL certificate. The steps are basically as below:
1. create a key pair
openssl genrsa -des3 -out applicant.key 2048
2. create a certificate signing request
openssl req -new -sha256 -nodes -out applicant.csr -key applicant.key -config someCert.csr.cnf
3. create a cert for the applicant using the ca.key(private key) and cacert.pem (CA certificate)
openssl x509 -req -in applicant.csr -CA cacert.pem -CAkey ca.key -CAcreateserial -out applicant.crt -days 500 -sha256 -extfile localdomain.v3.ext
I got a few question regarding the steps.
a) When we create the key in step 1, is it a key pair or just private key?
b) When creating a certificate signing request in step 2, do we need a public key or private key?
c) When create a cert from CA, why do we need both ca private key and ca certificate? I believe the ca private key is used for digital signature, but what's the purpose of CA certificate?
When we create the key in step 1, is it a key pair or just private key?
applicant.key contains both the public and private elements. You can see them with openssl rsa -text -nout -in applicant.key, or in a more basic form with dumpasn1 or similar.
When creating a certificate signing request in step 2, do we need a public key or private key?
Both. You need the public key as that is going to be certified by the CA. You need the private key as you sign the CSR with this to provide Proof of Possession of the public key.
When create a cert from CA, why do we need both its private key and ca certificate?
Again, both. You need the private key in order to sign the certificate. You also need the CA certificate so that the CA can extract information used during the signing process from it.
As a minimum, this is the Subject field of the CA certificate which is used as the Issuer field of the signed certificate.
Another example is the AuthorityKeyIdentifier extension in the CA certificate, whose value is used as the SubjectKeyIdentfier extension in the applicant's certificate.
However, CAs are at liberty to use whatever they need. For example, Microsoft CAs will check the expiry date on the CA certificate and not issue an applicant a certificate that expires past this date (it truncates the validity of the certificate). In order to do that, it needs access to the CA certificate.
From here, I learnt that, we need a public key and user identification:
to create CSR
Goal is to establish SSL/TLS connections between two nodes(client & server).
Based on the above diagram, my understanding is, to give public key as input to create CSR but step 4 uses private key(server-key.pem) to create CSR(server.CSR)
Step 1) Create certificate authority key(private key)
$ openssl genrsa -aes256 -out ca-key.pem 4096
Step 2) Create Certificate authority(root certificate) with the input(ca-key.pem)
$ openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem
Step 3) Create a private key for web server
$ openssl genrsa -out server-key.pem 4096
Step 4) Create Certificate signing request(CSR) by entering user identification. This will create public key in-turn.
$ openssl req -subj "/CN=dockerbuild.harebrained-apps.com" -sha256 -new -key server-key.pem -out server.csr
Step 5) Add the configuration
$ echo subjectAltName = IP:40.xx.xx.164,IP:10.0.0.4,IP:127.0.0.1,DNS:dockerbuildsys.westus.cloudapp.azure.com,DNS:dockerbuild.harebrained-apps.com > extfile.cnf
Step 6) Create server certificate
$ openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf
Step 7) Create client private key
$ openssl genrsa -out key.pem 4096
Step 8) Create CSR for client by entering user identification
$ openssl req -subj '/CN=client' -new -key key.pem -out client.csr
Step 9) Certificate extension file for client
$ echo extendedKeyUsage = clientAuth > extfile.cnf
Step 10) Create client certificate
$ openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf
Step 11) Removing signing requests
$ rm -v client.csr server.csr
Step 12) Remove write permissions on keys
$ chmod -v 0400 ca-key.pem key.pem server-key.pem
Step 13) Read permissions to certificate for every user
$ chmod -v 0444 ca.pem server-cert.pem cert.pem
Step 14) Uploaded on server side, Certificate authority(ca.pem), server certificate(server-cert.pem) & server key(server-key.pem)
I have very good understanding on symmetric and asymmetric key encryption.
We use asymmetric keys to solve key distribution problem(symmetric key) between two parties
I understand that, every certificate has public key + Identity of owner(that provides certificate)
Questions:
1) Are ca-key.pem, server-key.pem & key.pem symmetric keys?
2) Why to create Certificate authority(ca.pem)? Why do we need a private key(ca-key.pem) to create Certificate authority?
3) Why do we need a private key to create CSR? Because it contradicts with the diagram(above)?
4) Why to create Certificate Signing Request(CSR) before creating a certificate? both client & server
5) Why do we need two certificates(server certificate server-cert.pem & client certificate cert.pem)?
6) Does openssl req -subj "/CN=dockerbuild.harebrained-apps.com" -sha256 -new -key server-key.pem -out server.csr create server.csr that contain a public key + user identification? If yes, how this public key different from the public key provided by certificate(server-cert.pem)?
7) If there are no symmetric keys created in the above process, then how client & server communicate with encryption?
8) How server-key.pem/server-cert.pem/ca.pem(uploaded on server) work with key.pem/cert.pem/ca.pem(on client)?
1) Are ca-key.pem, server-key.pem & key.pem symmetric keys?
These are asymmetric keys. There are no symmetric keys at all involved when creating certificates. Symmetric keys are only involved for the actual encryption in TLS.
2) Why to create Certificate authority(ca.pem)? Why do we need a private key(ca-key.pem) to create Certificate authority? Because it contradicts with the diagram(above)
A CA is a trust anchor. The private key of the CA is used to issue (sign) new certificates. The CA certificate containing the public key is trusted by the party which likes to verify the certificate. See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? to get a better idea how CA certificates and leaf certificates and signatures (done using the private key) play together.
It is not actually necessary to have a CA, i.e. one could use a self-signed certificate. But in this case each party who like to verify the connection using the certificate needs to have some previous knowledge of each self-signed certificate it should be able to verify. This does not scale well, i.e. it is easier to explicitly trust a CA and then derive from this trust into the certificates issues by the CA.
3) Why do we need a private key to create CSR? Because it contradicts with the diagram(above)?
The CSR gets signed to prove that you own the private key matching the public key in the CSR (and thus in the future certificate).
4) Why to create Certificate Signing Request(CSR) before creating a certificate? both client & server
Usually the CSR is created by a different party than the CA. In this case the CSR is a signed container which provides information about the certificate the party likes to have issued. It is not technically needed to create a certificate but organizationally.
5) Why do we need two certificates(server certificate server-cert.pem & client certificate cert.pem)?
We don't. Usually only the server certificate is needed to make sure that the client communicates with the correct server. Client certificates are only needed with mutual authentication where the server likes to authenticate the client too using a certificate.
6) Does server.csr contain a public key + user identification? If yes, how this public key different from the public key provided by certificate?
The public key in CSR is the same as in the certificate. There are user specific information in the certificate (the domain) but the CA must verify through other means that these information are actually correct (i.e. user owns the domain) before issuing the certificate.
7) If there are no symmetric keys created in the above process, then how client & server communicate with encryption?
The TLS handshake contains an authentication part (check that the server is the expected one based on the certificate) and a key exchange. The latter generates symmetric keys used for encrypting the application data. See How does SSL/TLS work? for the details.
8) How server-key.pem/server-cert.pem/ca.pem(uploaded on server) work with key.pem/cert.pem/ca.pem(on client)?
The private key of the server certificate is used to sign some challenge inside the TLS handshake in order to prove that the server owns the given certificate. The private key of the client certificate is used in a similar way if mutual authentication is done. The CA certificate is used to verify the certificate (again, see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?).