Skip to content

Instantly share code, notes, and snippets.

@aonurdemir
Created February 13, 2023 12:43
Show Gist options
  • Save aonurdemir/b58171094f7bc3872b17d225c285bfe7 to your computer and use it in GitHub Desktop.
Save aonurdemir/b58171094f7bc3872b17d225c285bfe7 to your computer and use it in GitHub Desktop.
Creating SSL Certificate and Root Certificate Authority key
#Reference: https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/
To request an SSL certificate from a CA like Verisign or GoDaddy, you send them a Certificate Signing Request (CSR), and they give you an SSL certificate in return that they have signed using their root certificate and private key. All browsers have a copy (or access to a copy from the operating system) of the root certificate from the various CAs, so the browser can verify that your certificate was signed by a trusted CA.
That’s why when you generate a self-signed certificate the browser doesn’t trust it. It hasn’t been signed by a CA. The way to get around this is to generate our own root certificate and private key. We then add the root certificate to all the devices we own just once, and then all the self-signed certificates we generate will be inherently trusted.
# Generating the Private Key and Root Certificate
brew install openssl
mkdir ~/certs
cd ~/certs
#With that set up, we’re ready to generate the private key to become a local CA:
openssl genrsa -des3 -out myCA.key 2048
OpenSSL will ask for a passphrase, which we recommend not skipping and keeping safe. The passphrase will prevent anyone who gets your private key from generating a root certificate of their own. The output should look like this:
Generating RSA private key, 2048 bit long modulus
.................................................................+++
.....................................+++
e is 65537 (0x10001)
Enter pass phrase for myCA.key:
Verifying - Enter pass phrase for myCA.key:
# Next, we generate a root certificate:
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 1825 -out myCA.pem
You will be prompted for the passphrase of the private key you just chose and a bunch of questions. The answers to those questions aren’t that important. They show up when looking at the certificate, which you will almost never do. I suggest making the Common Name something that you’ll recognize as your root certificate in a list of other certificates. That’s really the only thing that matters.
You should now have two files: myCA.key (your private key) and myCA.pem (your root certificate).
🎉 Congratulations, you’re now a CA. Sort of.
Then you should add the root certificate(myCA.pem) to the system.(macos, windows or linux)
# Creating CA-Signed Certificates for Your Dev Sites
Now we’re a CA on all our devices and we can sign certificates for any new dev sites that need HTTPS. First, we create a private key for the dev site. Note that we name the private key using the domain name URL of the dev site. This is not required, but it makes it easier to manage if you have multiple sites:
openssl genrsa -out hellfish.test.key 2048
# Then we create a CSR:
openssl req -new -key hellfish.test.key -out hellfish.test.csr
You’ll get all the same questions as you did above and, again, your answers don’t matter. In fact, they matter even less because you won’t be looking at this certificate in a list next to others.
Finally, we’ll create an X509 V3 certificate extension config file, which is used to define the Subject Alternative Name (SAN) for the certificate. In our case, we’ll create a configuration file called hellfish.test.ext containing the following text:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = hellfish.test
Now we run the command to create the certificate: using our CSR, the CA private key, the CA certificate, and the config file:
openssl x509 -req -in hellfish.test.csr -CA myCA.pem -CAkey myCA.key \
-CAcreateserial -out hellfish.test.crt -days 825 -sha256 -extfile hellfish.test.ext
We now have three files: hellfish.test.key (the private key), hellfish.test.csr (the certificate signing request, or csr file), and hellfish.test.crt (the signed certificate). We can configure local web servers to use HTTPS with the private key and the signed certificate.
We can use the crt file as certificate and key file as private key.
Done
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment