Squoggle
Mac's tech blog
Category Archives: SSL/TLS/OpenSSL
Online Certificate Status Protocol (OCSP)
Posted by on December 15, 2022
Online Certificate Status Protocol (OCSP) is an alternative method to Certificate Revocation Lists (CRLs) used to check the validity of digital certificates in a public key infrastructure (PKI).
When a user encounters a digital certificate, their software can use OCSP to send a request to the certificate authority (CA) to check the current status of the certificate. The CA responds to the request with one of three responses: “good”, “revoked”, or “unknown”.
If the response is “good”, the user’s software can proceed with the transaction or access to the resource protected by the certificate. If the response is “revoked”, the software rejects the certificate as invalid. If the response is “unknown”, the software may require additional steps to verify the validity of the certificate.
Unlike CRLs, which can become large and unwieldy as the number of revoked certificates increases, OCSP allows for more efficient and timely checking of individual certificates. However, it requires a constant connection to the CA to receive real-time status updates and can be subject to performance and privacy concerns.
The Good about OCSP
- Real-time validation: OCSP provides real-time validation of certificates, so users can immediately determine whether a certificate is valid or not.
- Smaller and more efficient: OCSP responses are typically smaller and more efficient than certificate revocation lists (CRLs), especially for large PKIs with many revoked certificates.
- Reduced latency: OCSP can reduce latency by eliminating the need for users to download and parse large CRL files.
- More privacy-friendly: OCSP can be more privacy-friendly than CRLs, as it doesn’t require users to download a complete list of revoked certificates and associated information.
The Bad about OCSP
- Increased network traffic: OCSP requires users to contact the certificate authority (CA) server each time a certificate is validated, which can increase network traffic and cause performance issues.
- Single point of failure: OCSP relies on a single CA server for validation, so if the server goes down or experiences issues, users may be unable to validate certificates.
- Reduced reliability: OCSP may be less reliable than CRLs in certain situations, such as when there are issues with the CA’s OCSP server or network connectivity.
- Potential privacy concerns: While OCSP can be more privacy-friendly than CRLs, it still allows the CA to track which certificates are being validated and when, which may be a concern for some users.
Check the OCSP status of a Certificate
You can check an Online Certificate Status Protocol (OCSP) response with OpenSSL using the openssl ocsp command. Here is an example command:
openssl ocsp -issuer issuer_cert.pem -cert certificate.pem -url http://ocsp.server.com -text
This command checks the status of the certificate in certificate.pem by sending an OCSP request to the server at http://ocsp.server.com. The issuer_cert.pem file is the certificate of the issuer that signed the certificate.pem file. The -text option displays the response in human-readable text.
After running the command, you will receive an OCSP response that includes the status of the certificate. If the status is “good”, the certificate is valid. If the status is “revoked”, the certificate has been revoked by the issuer. If the status is “unknown”, the server was unable to provide a definitive response for the certificate.
Get the Certificate from a Site:
Lets use google.com as an example.
Get the Certificate for google.com and save it to a file named certificate.pem:
openssl s_client -connect google.com:443 -showcerts /dev/null | sed -n '/Certificate/,/-----END CERTIFICATE-----/p' | tail -n +3 > certificate.pem
Get the Issuing Cert from a Site:
Get the issuing certificate for google.com and save it to a file named issuer.pem:
openssl s_client -connect google.com:443 -showcerts /dev/null | sed -n '/1 s:/,/-----END CERTIFICATE-----/p' | tail -n +3 > issuer.pem
Extract the OCSP URL from the Certificate:
Use OpenSSL to get the OCSP URL from the Certificate and save it to a variable name ocspurl:
ocspurl=$(openssl x509 -in certificate.pem -noout -text | grep "OCSP" | cut -f2,3 -d:)
Test the OCSP Status of the Certificate:
Check the status of the OCSP status of the certificate using the ocsp flag to OpenSSL like this:
openssl ocsp -issuer issuer.pem -cert certificate.pem -url $ocspurl -text
You should get a response that looks something like this:
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 12D78B402C356206FA827F8ED8922411B4ACF504
Issuer Key Hash: A5CE37EAEBB0750E946788B445FAD9241087961F
Serial Number: 0CD04791FC985ABB27E20A42A232FDF5
Request Extensions:
OCSP Nonce:
0410CD24FED402FF2B1D2331485C81AD1C21
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: A5CE37EAEBB0750E946788B445FAD9241087961F
Produced At: Apr 26 00:54:27 2023 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 12D78B402C356206FA827F8ED8922411B4ACF504
Issuer Key Hash: A5CE37EAEBB0750E946788B445FAD9241087961F
Serial Number: 0CD04791FC985ABB27E20A42A232FDF5
Cert Status: good
This Update: Apr 26 00:39:01 2023 GMT
Next Update: May 2 23:54:01 2023 GMT
Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:45:c2:eb:e2:54:23:2a:c5:49:47:c2:f0:0b:cf:
8d:06:6d:17:62:26:2e:4a:ba:8e:cd:61:bf:dd:af:e8:ea:cb:
02:21:00:94:bd:5c:33:e7:ac:20:50:d4:15:45:9e:d8:8d:75:
1a:fb:c5:95:5f:11:c7:b2:88:47:0a:5b:56:d0:3c:89:b5
WARNING: no nonce in response
Response verify OK
certificate.pem: good
This Update: Apr 26 00:39:01 2023 GMT
Next Update: May 2 23:54:01 2023 GMT
OpenSSL OCSP Commands Documentation
Online Certificate Status Protocol command
Certificate Revocation List (CRL)
Posted by on December 15, 2022
Certificate Revocation Lists (CRLs) are used in public key infrastructure (PKI) to identify digital certificates that have been revoked by the certificate authority (CA) before their expiration date.
When a CA revokes a digital certificate, it adds the certificate’s serial number to the CRL. The CRL is then distributed to users who rely on the PKI, such as web browsers and other software that verify digital certificates.
When a user encounters a digital certificate that has been revoked, their software checks the CRL to confirm that the certificate is no longer valid. If the certificate’s serial number is listed on the CRL, the software will reject the certificate and prevent the user from accessing the website or resource protected by the certificate.
CRL Expiration
The client typically gets a new Certificate Revocation List (CRL) from the Certificate Authority (CA) when the existing CRL expires or when there have been changes to the status of certificates that have been revoked.
When a CA revokes a digital certificate, it adds the certificate’s serial number to the CRL. The CRL contains a list of all the revoked certificates, along with their revocation status and the reason for revocation.
The CRL has an expiration date and time, after which it is no longer considered valid. The expiration date is typically set by the CA when the CRL is issued, and it is usually a few days to a few weeks after the issue date. When the CRL is about to expire, the client will check with the CA to obtain a new CRL that is valid for the next period.
In addition to the expiration date, the client may also obtain a new CRL if there are changes to the revocation status of certificates that have been previously listed in the CRL. This can happen if a certificate that was previously revoked is now reinstated, or if a certificate that was previously valid is now revoked.
The client can obtain a new CRL from the CA via various means, such as through online updates or downloads. Some PKIs also use alternative methods of certificate revocation, such as Online Certificate Status Protocol (OCSP), which can provide real-time updates on the status of certificates.
The Good about CRL
- Offline validation: CRLs can be downloaded and stored offline, allowing users to validate certificates even when they are not connected to the network.
- No single point of failure: Unlike OCSP, CRLs don’t rely on a single server for validation, so they are less susceptible to single points of failure.
- Better reliability: CRLs may be more reliable than OCSP in certain situations, such as when the CA’s OCSP server or network connectivity is experiencing issues.
- Can cover multiple certificates: A single CRL can cover multiple certificates, reducing the amount of data that needs to be downloaded and parsed.
The Bad about CRL
- Larger size: CRLs can become large and unwieldy as the number of revoked certificates increases, leading to longer download times and increased storage requirements.
- Increased latency: CRLs can introduce latency into the certificate validation process, as users must download and parse the entire CRL before they can validate a certificate.
- May be outdated: CRLs are typically updated on a periodic basis, so there is a risk that a certificate may have been revoked between updates and the user may not be aware of it.
- May present a privacy risk: CRLs can potentially expose information about revoked certificates, which could be used by attackers to gather information about a PKI.
Overall, CRLs can be an effective means of validating certificates in a PKI, especially in situations where offline validation is important or when the number of revoked certificates is relatively small. However, they also have some drawbacks that should be considered, such as larger size, increased latency, and potential privacy risks.
Delta CRL
A Delta Certificate Revocation List (CRL) is a type of CRL that contains only the revoked certificates that have been added or changed since the previous CRL was issued. The Delta CRL is meant to be used in conjunction with the base CRL, which contains the complete list of revoked certificates.
The Delta CRL is a more efficient way of distributing certificate revocation information, as it contains only the changes to the previous CRL, rather than the entire list of revoked certificates. This can significantly reduce the size of the CRL and the time it takes to download and process it.
To use a Delta CRL, the client first downloads the base CRL, which contains the complete list of revoked certificates. The client then downloads the Delta CRL, which contains only the changes since the previous CRL. The client then merges the Delta CRL with the base CRL to obtain a complete and up-to-date list of revoked certificates.
The use of Delta CRLs can help to improve the efficiency of certificate revocation in large PKIs, especially when the number of revoked certificates is high and changes occur frequently. However, the use of Delta CRLs also requires additional management and coordination between the CA and the client, as both parties must ensure that the Delta CRL is properly applied and merged with the base CRL.
Troubleshooting CRL
Sometimes you may need to troubleshoot certificate issues by examining a CRL (Certificate Revocation List)
Download a CRL
These instructions show how you can easily download a CRL from a website. I’ll use https://duckduckgo.com/ in this example.
- Open Google Chrome. Navigate to https://duckduckgo.com/. Notice the padlock in the address bar.
- Right click on the padlock in the address bar. Click Connection is secure to see the connection details.
- Click Certificate is valid to open the certificate details box. Click the Details tab.
- In the Certificate Fields box, scroll down and click on CRL Distribution Points. In the Field Value box you will see any URLs associated with the CRL for the Certificate Authority or the Signing Certificate.
- Copy and paste the URL into a new window of the browser. You will be prompted to save the file. In my case I downloaded a file named DigiCertTLSRSASHA2562020CA1-4.crl.
Parse the CRL
- Open a terminal in the directory where you saved the CRL.
- Check to see if the CRL is in DER format or PEM format. Most CRLs are in DER format. If you do a simple head command on the CRL file you will see if it is a DER (binary) file or a PEM file. If it is binary you will see gibberish. If it is a PEM formatted file you will see ,“BEGIN X509 CRL—–”.
- Parse the CRL. If the CRL is in DER format use this syntax:
openssl crl -inform DER -text -noout -in [crl-file] | less
If the CRL is in PEM format use this syntax:openssl crl -inform PEM -text -noout -in [crl-file] | less - You will see a list of all the revoked certificates that were issued by the Issuing Certificate.
OpenSSL CRL Commands Documentation
The OpenSSL CRL commands official documentation:
TLS 1.2 vs. TLS 1.3: Exploring the Key Differences and Advancements in Security
Posted by on November 17, 2022
Introduction
Transport Layer Security (TLS) is a widely-used cryptographic protocol that provides secure communications over a computer network, such as the Internet. TLS ensures that the data transmitted between a client and a server is encrypted and protected from eavesdropping and tampering. In this blog post, we will discuss the key differences between TLS 1.2 and TLS 1.3, the latest version of the protocol, and explore how TLS 1.3 offers improved security, performance, and privacy compared to its predecessor.
Faster and More Efficient Handshake Process
One of the most significant improvements in TLS 1.3 is the streamlined and efficient handshake process. In most cases, TLS 1.3 reduces the number of round trips between the client and server to just one, speeding up the connection establishment. This improvement is particularly beneficial for latency-sensitive applications like web browsing, providing a more responsive user experience.
Modern and Secure Cryptographic Algorithms
TLS 1.3 supports only modern and secure cryptographic algorithms, removing outdated and vulnerable ciphers that were still allowed in TLS 1.2. By eliminating weak ciphers and focusing on strong encryption techniques, TLS 1.3 offers better resistance to attacks and cryptographic weaknesses. For example, TLS 1.3 no longer supports the RSA key exchange, which is vulnerable to several attacks.
Mandatory Forward Secrecy
Forward secrecy is a security feature that ensures that even if a server’s private key is compromised, past communication sessions cannot be decrypted. While forward secrecy was optional in TLS 1.2, it is mandatory in TLS 1.3. This is achieved by using ephemeral (short-lived) keys for each session, which are discarded after use, further enhancing the security of the protocol.
Simplified Protocol Design
TLS 1.3 boasts a simpler and cleaner design compared to TLS 1.2, as it has removed many features and options that were either outdated or considered insecure. This streamlined design makes the protocol easier to implement, understand, and analyze, reducing the likelihood of implementation errors and security vulnerabilities.
Zero Round-Trip Time (0-RTT) Resumption
A new feature introduced in TLS 1.3 is the 0-RTT resumption, which allows clients to send encrypted data to a server during the initial handshake, without waiting for the handshake to complete. This can significantly improve performance in certain scenarios, such as when a client is reconnecting to a previously-visited server. However, this feature can also introduce some security risks, and its use should be carefully evaluated.
Conclusion
TLS 1.3 offers several advantages over TLS 1.2, including improved security, performance, and privacy. Its adoption has been growing steadily, and it is now the recommended version for securing communications over the Internet. However, it is important to note that while TLS 1.3 is superior, TLS 1.2 is still considered secure when properly configured with modern ciphers and settings. By understanding the key differences between these two versions, organizations can make informed decisions about their security infrastructure and ensure the highest level of protection for their users.
The TLS 1.2 Handshake Explained: Securing Your Online Data with a Twist
Posted by on October 13, 2022
Introduction
Howdy, folks! In today’s digital age, the need for secure online communication is more important than ever. And that’s where the Transport Layer Security (TLS) protocol comes in. It’s the trusty sidekick that keeps your sensitive data safe from prying eyes. In this blog post, we’re going to take a down-home look at the TLS 1.2 handshake process to help you understand how it ensures secure communication between your computer and the websites you visit.
1. The Meet and Greet
When you decide to visit a secure website, your computer (the client) and the website’s server start a friendly little dance called the TLS handshake. The first step of this dance is the “Client Hello” message, where your computer sends a list of its preferred cryptographic algorithms and a random number to the server. It’s sort of like saying, “Howdy, partner! These are the steps I know. What about you?”
2. The Server’s Response
Next, the server picks the best matching cryptographic algorithms and sends a “Server Hello” message back to the client, sharing its own random number. In addition, the server sends its digital certificate, which is like a digital ID card, to prove its identity. It’s the server’s way of saying, “Well, howdy! I reckon we can dance to the same tune. Here’s my ID, just so you know I’m legit.”
3. Checking Credentials
Your computer takes a gander at the server’s certificate and verifies it with the certificate authority (CA) that issued it. If everything checks out, your computer says, “Well, alrighty then! You seem like a fine partner for this dance.”
4. The Secret Handshake
Now that both sides have agreed on the steps, it’s time to create a secret key for encrypting and decrypting the data. Your computer generates a “pre-master secret” and encrypts it with the server’s public key from its certificate. This encrypted pre-master secret is then sent back to the server, which decrypts it with its private key. It’s like sharing a secret handshake that only the two of them will know.
5. Securing the Dance Floor
With the pre-master secret securely exchanged, both your computer and the server derive the same “master secret.” From this master secret, they generate symmetric encryption keys and other required cryptographic material. It’s like setting up a private dance floor, so no one can see or interfere with your moves.
6. The Final Steps
Finally, both the client and the server send “Change Cipher Spec” and “Finished” messages to each other, indicating that they’re ready to start using the newly established encryption keys. It’s like saying, “Alright, partner, let’s start dancing with our new secret steps!”
Conclusion
And there you have it, folks! That’s the TLS 1.2 handshake in a nutshell. This trusty process keeps your online chats safe and sound, ensuring that your sensitive data is encrypted and secure from eavesdroppers. So the next time you visit a secure website or send a confidential email, remember to tip your hat to the hardworking TLS 1.2 handshake that keeps your information safe as houses.
Validate a Certificate’s Chain
Posted by on April 30, 2020
You can validate a Certificate’s chain by extracting the Authority Key Identifier from the cert like this:
$ openssl x509 -text -in [cert-name].crt | grep -A 1 "Authority Key Identifier"
You should get a result similar to this:
X509v3 Authority Key Identifier: keyid:FC:8A:50:BA:9E:B9:25:5A:7B:55:85:4F:95:00:63:8F:E9:58:6B:43
This is the Key Identifier from the Intermediate Cert. This should match up with the “Subject Key Identifier” of the Intermediate Cert.
Get the “Subject Key Identifier” of the Intermediate Cert:
$ openssl x509 -text -in [intermediate-cert-name].crt | grep -A 1 "Subject Key Identifier"
You should get a result similar to this:
X509v3 Subject Key Identifier: FC:8A:50:BA:9E:B9:25:5A:7B:55:85:4F:95:00:63:8F:E9:58:6B:43
If the two identifiers match then you have the correct Intermediate Cert for the Cert.
You can now repeat the process with the Intermediate Cert and the root Cert and validate that the root cert you have is the one for the Intermediate.
Convert PEM certificate to PFX or P12
Posted by on February 14, 2020
How to convert a PEM certificate to PFX or P12 format.
The PFX or PKCS12 format is a binary format that stores a server certificate, any intermediate certificates, along with the private key into a single encrypted file. PFX files typically have the .pfx and .p12 extensions. PFX files are typically used on Windows machines and macOS machines to import and export certificates and private keys. Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores. The JKS format is Java’s standard “Java KeyStore” format, and is the format created by the keytool command-line utility. The PKCS12 format is an internet standard, and can be created with OpenSSL.
What you’ll need:
- You will need the private key that was used to create the public key and certificate.
- You will need the certificate in PEM format, typically with file extension of .crt, .pem or .cer.
- You will need Openssl.
Lets take a look at the Openssl command you would use to convert the PEM cert to PFX:
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile chain.crt
Lets break down the different parts of the command to see what they do:
openssl – This starts the openssl software.
pkcs12 – This tells openssl to use PKCS#12 Data Management.
-export -out certificate.pfx – This tells openssl to export out a PFX file named certificate.pfx.
-inkey privateKey.key – This tells openssl to import the private key from a file named privateKey.key.
-in certificate.crt – This tells openssl to import the certificate from a file named certificate.crt.
-certfile chain.crt – This tells openssl to include any additional certificates contained in chain.crt you want to include in the PFX file. Typically this would be any Intermediate Certs that chain your cert to a root cert.
After you enter this command you will be prompted for a password that protects the PFX file. Without the password the PFX file is useless so do not forget it.
The end result of this command will be that you have a new file named certificate.pfx which contains your Private Key, the Certificate and any Intermediate certs you added as well, all wrapped into a binary format and protected by a password.
Extract data from a Certificate
Posted by on September 16, 2019
Get Info from a Cert:
Using the -text option will give you the full breadth of information:
$ openssl x509 -text -in [cert-file.crt]
This will show a long list of what’s contained in a cert. You can pipe to less if needed.
Extract what cert issued the cert:
$ openssl x509 -noout -in [cert-file.crt] -issuer
Who the certificate was issue to:
$ openssl x509 -noout -in [cert-file.crt] -subject
For what dates is it valid:
$ openssl x509 -noout -in [cert-file.crt] -dates
Expiration date:
$ openssl x509 -noout -in [cert-file.crt] -enddate
Get Serial Number from a Cert:
$ openssl x509 -noout -in [cert-file.crt] -serial
All of the above at once:
$ openssl x509 -noout -in [cert-file.crt] -issuer -subject -dates -serial
Get Signature Algorithm:
$ openssl x509 -text -in [cert-file.crt] | grep 'Signature Algorithm'
Get hash value:
$ openssl x509 -noout -in [cert-file.crt] -hash
Get MD5 fingerprint:
$ openssl x509 -noout -in [cert-file.crt] -fingerprint
Get Modulus of Cert (1024 or 2048):
$ openssl x509 -text -in [cert-file.crt] | grep Modulus
Get SANs from a Cert:
$ openssl x509 -text -in [cert-file.crt] | grep -A 1 Alternative
Verifying Certs, Keys & CSRs – MD5 Sum
Posted by on September 14, 2019
Sometimes you will need to verify that a Cert or a CSR belong to a Key. You can do that by checking the MD5 sum of each file.
Get the MD5 sum from the Key:
$ openssl rsa -noout -modulus -in [key-file.key] | openssl md5
Get the MD5 sum from a CSR:
$ openssl req -noout -modulus -in [CSR-file.csr] | openssl md5
Get the MD5 sum from a Cert:
openssl x509 -noout -modulus -in [certificate-file.crt] | openssl md5
Compare the resulting numbers. If they match then your files belong to each other. If they don’t match then there has been a mixup in the files somehow.
OpenSSL Keys & CSRs
Posted by on September 14, 2019
An in depth read on OpenSSL for perusal.
https://wiki.nikhef.nl/grid/How_to_handle_OpenSSL_and_not_get_hurt_using_the_CLI
Create an Encrypted Key:
For Linux:
$ openssl genrsa -aes256 -out [encrypted.key] 2048 Generating RSA private key, 2048 bit long modulus ......+++ .......................+++ e is 65537 (0x10001) Enter pass phrase for [encrypted.key]: Verifying - Enter pass phrase for [encrypted.key]:
Enter the passphrase and verify.
You should end up with the key file in the format of [encrypted.key]
The above encrypts the key with aes256 cipher.
Create an un-encrypted key:
Optionally you can create an un-encrypted or insecure key:
$ openssl genrsa -out [un-encrypted.key] 2048
You should end up with the key file in the format of [un-encrypted.key] but the key is not encrypted.
Decrypt an encrypted key:
If you have an encrypted key and need to decrypt it:
$ openssl rsa -in [encrypted.key] -out [un-encrypted.key] Enter pass phrase for [encrypted.key]: writing RSA key
Enter the passphrase.
You should end up with a new file in the format of [un-encrypted.key]. This new file will contain the un-encrypted key.
Encrypt an un-encrypted key:
If you have an un-encrypted key and you want to encrypt it:
$ openssl rsa -aes256 -in [un-encrypted.key] -out [encrypted.key]
Enter the passphrase and verify.
You should end up with the key file in the format of [encrypted.key]
The above encrypts the key with aes256 cipher.
Check a key to see if it is encrypted:
If you’re not sure if the key is encrypted you can simply assume it is encrypted and attempt to decrypt it with no out file:
$ openssl rsa -text -noout -in [encrypted.key]
If it is encrypted it will ask for the password.
Or simply look at the first few lines of the key file to see if it is encrypted:
$ head www.jimmysbarandgrill.com.key -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC,08C9A49D5267E47563D31DCE27429389 yJj1gFqTrRuc8VBX9Rx7LZYlmLV0+WutvYhrMBjTU+8ZDBIsmeEDxW44durw/BjS i07biVOwAIMwW7hE9oAYOiJy5JqgYuMtVT/hMwEvP9t/8ME4FUCZ1MUxGR25hg5H
Create a CSR (Certificate Signing Request) from a Key:
The key can be an encrypted key or an un-encrypted key. If it is encrypted you will be asked for the key password.
Example:
$ openssl req -new -key www.jimmysbarandgrill.com.key -out www.jimmysbarandgrill.com.csr Enter pass phrase for www.jimmysbarandgrill.com.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Idaho Locality Name (eg, city) []:Pocatello Organization Name (eg, company) [Internet Widgits Pty Ltd]:Jimmy's Bar and Grill Organizational Unit Name (eg, section) []:Dishwashing Common Name (e.g. server FQDN or YOUR name) []:www.jimmysbarandgrill.com Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Keep in mind that the State must not be abbreviated. You should not use a challenge password. You should not use an optional company name.
Create a CSR from a Key with one liner command:
You can create the CSR from an existing Key with a one liner command or non-interactively with something like this:
openssl req -new -key www.jimmysbarandgrill.com.key -out www.jimmysbarandgrill.com.csr -subj "/C=US/ST=Idaho/L=Pocatello/O=Jimmy's Bar and Grill/OU=Dishwashing/CN=www.jimmysbarandgrill.com"
The above command assumes you already have a key created with the key name listed in the command.
Create an Un-encrypted Key & CSR with one liner command:
You can create the Un-encrypted Key and CSR with one command like this:
Example:
$ openssl req -new -newkey rsa:2048 -nodes -sha256 -out www.jimmysbarandgrill.com.csr -keyout www.jimmysbarandgrill.com.key -subj "/C=US/ST=Idaho/L=Pocatello/O=Jimmy's Bar & Grill/OU=Dishwashing/CN=www.jimmysbarandgrill.com"
The above command uses the -nodes flag to turn off encryption of the key.
Create an Encrypted Key & CSR with one liner command:
You can create an Encrypted Key with accompanying CSR with one command like this:
Example:
$ openssl req -new -newkey rsa:2048 -sha256 -out www.jimmysbarandgrill.com.csr -keyout www.jimmysbarandgrill.com.key -subj "/C=US/ST=Idaho/L=Pocatello/O=Jimmy's Bar & Grill/OU=Dishwashing/CN=www.jimmysbarandgrill.com"
Essentially you just remove the -nodes flag. This does not seem to give the opportunity of specifying the cipher to use on encrypting the key. This may or may not matter depending on the security posture. If it is important I’ve come up with a workaround hack one liner that seems to work:
$ openssl req -new -newkey rsa:2048 -nodes -sha256 -out www.jimmysbarandgrill.com.csr -keyout www.jimmysbarandgrill.com.key -subj "/C=US/ST=Idaho/L=Pocatello/O=Jimmy's Bar & Grill/OU=Dishwashing/CN=www.jimmysbarandgrill.com" && openssl rsa -aes256 -in www.jimmysbarandgrill.com.key -out www.jimmysbarandgrill.com.key
The above example creates an un-encrypted key, creates the CSR from it, then encrypts the key. This command will result in an encrypted key file named www.jimmysbarandgrill.com.key and a CSR file named www.jimmysbarandgrill.com.csr.
Now all I need to do is figure out how to remove the automatic hyperlinks on these file names above.
Check a CSR:
Now that you have the CSR you should check it to ensure it is valid. Here’s a command to display the contents of the CSR:
$ openssl req -noout -text -in [CSR-File.csr]
Using the example of the CSR that was just created it would look something like this:
$ openssl req -noout -text -in www.jimyysbarandgrill.com.csr
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=US, ST=Idaho, L=Pocatello, O=Jimmy's Bar & Grill, OU=Dishwashing, CN=www.jimyysbarandgrill.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:bc:f0:e5:f5:c6:97:01:0b:ba:59:fd:2a:97:09:
4f:42:05:4c:53:bc:c3:8b:75:e6:e3:2b:e2:f7:1f:
8b:90:38:16:73:40:5e:f3:2a:ad:04:73:06:12:6e:
40:ff:4d:1a:b9:e4:41:07:d6:db:96:d4:fa:61:9a:
5f:03:fa:f9:92:d7:a0:19:56:1c:64:e7:4d:d6:cf:
ea:27:0e:b6:09:cd:22:e2:99:c3:66:8f:f2:ef:96:
aa:cc:6f:c7:a9:2c:79:28:20:91:6d:b8:2a:96:40:
bd:b2:60:b7:2f:59:1b:04:30:5d:1f:85:26:81:6b:
61:9e:8c:be:a5:bd:d3:3d:39:b7:86:d6:9a:30:74:
fe:59:a1:d6:39:7a:8b:f2:26:62:e2:3d:c6:a9:fe:
66:dd:9d:21:07:c4:c9:5b:12:93:21:22:7c:f2:d5:
21:0b:a8:89:bc:b3:b0:99:6d:d9:3c:d0:1d:6a:a7:
8c:90:64:e2:12:2a:ea:a7:49:e2:80:01:91:c9:da:
32:b5:41:6d:ae:ad:f2:77:a2:48:f4:66:6e:f1:35:
5f:47:f2:c9:4e:99:0b:9c:77:ff:71:19:43:b8:0b:
fe:74:0d:a4:bd:9c:e0:b0:ae:71:0b:4f:db:09:0d:
9b:91:46:e8:dc:db:ea:42:27:b8:ba:10:56:d0:6b:
0a:17
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5b:38:5f:10:f4:0a:73:05:b7:e3:21:f8:d2:3b:ee:e7:dd:4b:
65:d0:f8:bc:47:7d:0d:d4:fa:9b:28:6d:6c:52:be:74:de:62:
e1:ae:99:fc:85:e6:99:65:a2:c8:b7:56:5a:0f:aa:49:ff:f8:
68:ed:9d:6f:48:75:49:78:8e:67:95:39:ee:96:bc:f3:20:8f:
a3:31:7a:a8:49:30:80:7a:f4:27:41:ba:91:ba:ad:63:84:06:
95:70:86:2b:be:e2:0f:9a:26:d4:21:34:61:c2:21:d2:75:51:
3f:39:fa:ed:f1:92:d5:ff:12:03:cb:1a:56:f8:c9:e5:6d:00:
78:61:c3:12:90:69:80:a0:c9:71:7e:42:ff:ce:f1:35:a1:08:
9e:fd:62:d8:77:8d:5d:74:4b:6d:41:1f:a4:f8:d6:14:c6:ca:
1f:bd:9a:8a:43:ac:da:bb:d6:4d:f9:d2:15:a1:5f:59:b0:da:
82:78:64:67:39:d9:49:49:1a:e6:7d:9e:bf:5d:11:0b:fb:57:
3d:f0:c5:64:da:15:a7:d7:28:63:4e:5d:7f:0c:2e:e6:7d:2e:
f5:8c:43:36:1e:3b:15:52:cc:5a:cc:82:50:23:09:c8:fa:63:
ff:19:30:6a:1a:ed:63:b5:5d:c0:be:20:67:3d:01:8b:b0:4d:
0d:01:8e:af
Get Public Key from a Private Key
You can get the Public Key from a Private Key with something like this:
$ openssl pkey -in [private.key] -pubout -out [public.key]
Squoggle 
Recent Comments