posted on 2014-07-10 14:37:52
This post should give an overview on the most used OpenSSL commands, and how SSL/TLS/X.509 in general works.
Since this post was written a long time ago, it might get revisited in the future. But this will be a major overhaul, so this will not happen in the near future either.
But there will come some ascii art on a schematic PKI in general, the section about the filenames will get cleaned up as well as the openssl section.
The most used terms are abbreviated in the following.
PK = Private Key
C = Certificate
CSR = Certificate Signing Request
CA = Certificate Authority
Usually this seems way harder than it is in reality, once you get the hang of it. Hardest part is to understand which file belonging to which server is needed for the current step.
Some more abbreviations first:
SSL : Secure Sockets Layer
TLS : Transport Layer Security
X.509 : Public Key Infrastructure (PKI) and Priviledge Management Infrastructure (PMI) standard by the "International Telecommunication Union Telecommunication Standardization Sector" (ITU-T).
SSL and its successor TLS, which includes SSL, are protocols for encrypting internet communication. The C infrastructure setup is defined in the X.509 standard. That is why these acronyms are popping up in any discussion about this topic.
On a sidenote, a more general equation:
HTTPS = HTTP + SSL/TLS + TCP
Since this post is focused on usability, the techniques in question that are used in a PKI or PMI are of no concern here.
The C chain looks usually like this: (intermeadiates can, but need not exist)
The last C is the one issued by the CA where you subitted your CSR to.
There exist a bunch of file types, you have to be able to differentiate.
.key : private key file (PK), but that's just a convention
.csr : certificate signing request (CSR)
.crt : certificate (C)
.cer : certificate (C), Microsoft used this naming scheme earlier
For .pem and .der files, see next section.
C.crt are kind of placeholders for your actual filenames in the following sections.
A good naming scheme would be
subdomain_domain_tld-year, without dots.
Dots happen to either not work or cause other problems.
Appending the year your C was issued helps with distinguishing in case you renew a certain certificate.
Containers are used for grouping together C's (and) into a single file.
.pem: ascii / base64 encoded container
.der: container in binary format
The extension hints at the encoding being used, for the container. A container usually consists of the set of all C's (the entire trust chain), and can optionally also contain the PK.
All the files from the section before can be in PEM or DER format, IIRC!
Generate a PK and a CSR:
openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout PK.key
If you already have an existing PK and just need a CSR:
openssl req -out CSR.csr -key PK.key -new
Create a new CSR for an existing C:
openssl x509 -x509toreq -in C.crt -out CSR.csr -signkey PK.key
Generation of a self-signed (ss) C, based on a newly generated PK with a term of validity of one year (365 days):
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout PK.key -out C.crt
ss-C's for https are still better than traffic over plain http, but for private websites for example, StartSSL Certificates provide C's for free. Free as in 'no money needed'.
openssl x509 -in C.crt -outform der -out C.der
openssl x509 -in C.crt -inform der -outform pem -out C.pem
For debugging reasons, this might actually be the most used command.
openssl x509 -in C.pem -text -noout openssl x509 -in C.crt -text -noout openssl x509 -in C.cer -text -noout
This will not work on a single PK file.
apt-get install gnutls-bin -y
Instead of the openssl tool suite, this is actually self-explanatory.
In the following, keyfiles are called
.key extension-wise, but that is just a name differentiation.
They are in reality just
.pem files, too, but with this practice files are easier to differentiate.
certtool --generate-privkey --outfile PK.key --rsa
--ecc flags if you want to change the used cryptosystem.
certtool --generate-request --load-privkey PK.key --outfile CSR.pem
Usually this is a CA_C.pem, a CA certificate.
certtool --generate-certificate --load-ca-privkey CA_PK.key --load-ca-certificate CA_C.pem --load-request CSR.pem --outfile C.pem
certtool --generate-certificate --load-ca-privkey CA_PK.key --load-ca-certificate CA_C.pem --load-privkey PK.key --outfile C.pem
certtool --generate-privkey --outfile CA_PK.key --rsa certtool --generate-self-signed --load-privkey CA_PK.key --outfile CA_C.pem
Here's a one-liner to copy-paste:
certtool --generate-privkey --outfile CA_PK.key --rsa && certtool --generate-self-signed --load-privkey CA_PK.key --outfile CA_C.pem
.p12 file includes all three part usually needed on the server side:
certtool --to-p12 --load-ca-certificate CA_C.pem --load-privkey PK.key --load-certificate C.pem --outfile CONTAINER.p12 --outder
certtool --certificate-info --infile C.pem
View posts from 2017-09, 2017-08, 2017-07, 2017-05, 2017-04, 2017-03, 2017-02, 2017-01, 2016-12, 2016-11, 2016-10, 2016-09, 2016-08, 2016-07, 2016-06, 2016-05, 2016-04, 2016-03, 2016-02, 2016-01, 2015-12, 2015-11, 2015-10, 2015-09, 2015-08, 2015-07, 2015-06, 2015-05, 2015-04, 2015-03, 2015-02, 2015-01, 2014-12, 2014-11, 2014-10, 2014-09, 2014-08, 2014-07, 2014-06, 2014-05, 2014-04, 2014-03, 2014-01, 2013-12, 2013-11, 2013-10