Using Openssl To Create Keys For Mac

1. Openssl Create Key
2. How To Use Openssl On Mac
3. Openssl Create Key Pair
4. Using Openssl To Create Keys For Mac Catalina

Create a new key. Openssl genpkey -algorithm RSA -pkeyopt rsakeygenbits:2048 -out store.scriptech.io.key.pem. Create a new CSR. Openssl req -new -sha256 -key store.scriptech.io.key.pem -config /etc/ssl/openssl.cnf -out store.scriptech.io.csr Verify the CSR. To view the contents of your new CSR, use the following command. The first step to generating keys is to create the bundle using OpenSSL. This approach allows us to specify a few extra options when creating keys that are normally hidden by ssh-keygen: $ openssl genpkey -algorith RSA -aes-256-cbc -outform PEM -out yourname.pem -pkeyopt rsakeygenbits:4096. The standard OpenSSH suite of tools contains the ssh-keygen utility, which is used to generate key pairs. Run it on your local computer to generate a 2048-bit RSA key pair, which is fine for most uses. It generates a private key using a standard elliptic curve over a 256 bit prime field. You can list all available curves using. Openssl ecparam -listcurves. Or you can use prime256v1 as I did. The second command generates a Certificate Signing Request and the third generates a self-signed x509 certificate suitable for use on web servers. To encrypt our private key, we use the following code: openssl rsa -in key.pem -des3 -out enc-key.pem Once the key file has been encrypted, you will then be prompted to create a password. Next, we can extract the public key from the file key.pem with this command: openssl rsa -in key.pem -pubout -out pub-key.pem.

OpenSSL is among the most popular cryptography libraries. It is most commonly used to implement the Secure Sockets Layer and Transport Layer Security (SSL and TLS) protocols to ensure secure communications between computers. In recent years, SSL has become basically obsolete since TLS offers a higher level of security, but some people have gotten into the habit of referring to both protocols as SSL.

Cryptography is tricky business, and OpenSSL has too many features to cover in one article, but this OpenSSL tutorial will help you get started creating keys and certificates.

OpenSSL tutorial: An introduction to internet security

When a client requests a secure connection to a server, the server, in turn, requests information to figure out which types of cryptographic security the client can support. Once it determines the most secure option, the following takes place:

1. The server sends a security certificate that is signed with the server's public key.
2. Once the client verifies the certificate, it generates a secret key and sends it to the server encrypted with the public key.
3. Next, both sides use the secret key to create two sets of public-private keys. At last, secure communication can commence.

SSL and TLS are two of many security protocols used to accomplish these steps. To implement these protocols, we need software like OpenSSL.

Abbreviations key

You'll come across tons of abbreviations in this guide and other OpenSSL tutorials. For quick reference, here is a short list of some terms you might encounter:

• CSR: Certificate Signing Request
• DER: Distinguished Encoding Rules
• PEM: Privacy Enhanced Mail
• PKCS: Public-Key Cryptography Standards
• SHA: Secure Hash Algorithm
• SSL: Secure Socket Layer
• TLS: Transport Layer Security

Part 1 - Getting started

You can download the source code for most platforms from the official OpenSSL website.

If you need a windows distribution, Shining Light Productions has a good one although there are plenty of alternatives. Once everything is successfully installed, let's begin by experimenting with the OpenSSL command line tool.

First, you can use the following command to display which version of OpenSSL you're running:

To get a full list of the standard commands, enter the following:

Check out the official OpenSSL docs for explanations of the standard commands. To view the many secret key algorithms available in OpenSSL, use:

Now, let's try some encryption. If you wanted to encrypt the text 'Hello World!' with the AES algorithm using CBC mode and a 256-bit key, you would do as follows:

You'll be prompted to enter a password from which the 256-bit secret key will be computed. In the above example, the password example is used, but you should have stronger passwords. You should now have a binary file called encrypted.bin that you can decrypt as follows:

Part 2 - Public and private keys

For the sake of example, we can demonstrate how OpenSSL manages public keys using the RSA algorithm. You can use other algorithms of course, and the same principles will apply. The first step is to generate public and private pairs of keys. Enter the following command to create an RSA key of 1024 bits:

You should now have a file called key.pem containing a public key and private key. As the file's name suggests, the private key is coded using the Privacy Enhanced Email, or PEM, standard. Use the following code to display it:

You should see a long combination of characters. For detailed information about how your key was generated, enter:

Openssl Create Key

This command should return information about the public and private exponents, the modulus and the other methods and numbers used to optimize the algorithm. In this context, the -noout option prevents display of the key in base 64 format, which means that only hexadecimal numbers are visible. The public exponent is an exception, of course, since it is always 65537 for 1024 bit keys.

To encrypt our private key, we use the following code:

Once the key file has been encrypted, you will then be prompted to create a password. Next, we can extract the public key from the file key.pem with this command:

Finally, we are ready to encrypt a file using our keys. Use the following format:

In the above context, is the file you want to encrypt. Since we're using RSA, keep in mind that the file can't exceed 116 bytes. The is the file containing the public key. If that file doesn't also include the private key, you must indicate so using -pubin. The is the encrypted file name.

Now, to decrypt the file, you can simply flip the equation. Change -encrypt to -decrypt, and switch the input and output files.

Part 3 - Creating digital signatures

At last, we can produce a digital signature and verify it. Signing a large file directly with a public key algorithm is inefficient, so we should first compute the digest value of the information to be signed. This can be accomplished using the following command:

In this example, is whichever algorithm you choose to compute the digest value. The is the file containing the data you want to hash while 'digest' is the file that will contain the results of the hash application. This war of mine: the little ones crack.

The next step is to compute the signature of the digest value as follows:

Finally, you can check the validity of a signature like so:

Here, signature is the filename of your signature, and key.pem is the file with the public key. To confirm the verification for yourself, you can compute the digest value of the input file and compare it to the digest value produced from the verification of the digital signature.

Part 4 - Certificate signing requests

Let's say that you want to create digital certificates signed by your own certificate authority. Before you can get an SSL certificate from a certificate authority, or CA, you must first generate a certificate signing request or a CSR. A CSR includes a public key as well as some extra information that gets inserted into the certificate when signed.

When you first create a CSR, you'll be asked to supply some information about yourself or your organization. In the field 'Common Name,' or CN, you must provide the fully qualified domain name of the host for which the certificate is intended. If you're actually purchasing an SSL certificate from a CA, then the information you provide should be factual and accurate! Imagine you want to secure an Apache HTTP or Nginx web server with HTTPS. You can use the following snippet to create a new 2048-bit private key along with a CSR from scratch:

Imagine you want to secure an Apache HTTP or Nginx web server with HTTPS. You can use the following snippet to create a new 2048-bit private key along with a CSR from scratch:

Just replace 'domain' with your domain name. Here, the -newkey rsa:2048 option tells OpenSSL that it should use the RSA algorithm to create a 2048-bit key, and the -nodes option indicates that the key shouldn't be password protected.

After you've provided all of the necessary information, your CSR will be generated. Now, you can send it to a CA and request an SSL certificate. If your CA supports SHA-2, be sure to add the -sha256 option if you want your CSR to be signable with SHA-2.

To create a CSR for a private key that already exists, you would use this format:

Again, replace domain with your domain name. The -key option here indicates that you're using an existing private key while -new indicates that you're creating a new CSR. In the prior example, -new was implied because you were making a new key.

Let's say you already have a certificate that you want to renew, yet you somehow lost the original CSR. Don't panic; you can generate a new one based on information from your certificate and the private key. For example, if you were using an X509 certificate, you'd use the following code:

The -x509toreq option is needed to let OpenSSL know the certificate type.

Part 5 - Generating SSL certificates

If you desire the extra security of an SSL certificate, but you can't afford or don't want to be bothered with a CA, a less expensive alternative is to sign your own certificates. Self-signed certificates are signed with their own private keys, and they are just as effective at encrypting data as CA-signed certificates; however, users might receive an alert from their browser indicating that the connection is not secure, so self-signed certificates are really only recommended in environments where you're not required to prove your service's identity such as on a non-public server.

To get a full list of the standard commands, enter the following:

Check out the official OpenSSL docs for explanations of the standard commands. To view the many secret key algorithms available in OpenSSL, use:

Now, let's try some encryption. If you wanted to encrypt the text 'Hello World!' with the AES algorithm using CBC mode and a 256-bit key, you would do as follows:

You'll be prompted to enter a password from which the 256-bit secret key will be computed. In the above example, the password example is used, but you should have stronger passwords. You should now have a binary file called encrypted.bin that you can decrypt as follows:

Part 2 - Public and private keys

For the sake of example, we can demonstrate how OpenSSL manages public keys using the RSA algorithm. You can use other algorithms of course, and the same principles will apply. The first step is to generate public and private pairs of keys. Enter the following command to create an RSA key of 1024 bits:

You should now have a file called key.pem containing a public key and private key. As the file's name suggests, the private key is coded using the Privacy Enhanced Email, or PEM, standard. Use the following code to display it:

You should see a long combination of characters. For detailed information about how your key was generated, enter:

Openssl Create Key

This command should return information about the public and private exponents, the modulus and the other methods and numbers used to optimize the algorithm. In this context, the -noout option prevents display of the key in base 64 format, which means that only hexadecimal numbers are visible. The public exponent is an exception, of course, since it is always 65537 for 1024 bit keys.

To encrypt our private key, we use the following code:

Once the key file has been encrypted, you will then be prompted to create a password. Next, we can extract the public key from the file key.pem with this command:

Finally, we are ready to encrypt a file using our keys. Use the following format:

In the above context, is the file you want to encrypt. Since we're using RSA, keep in mind that the file can't exceed 116 bytes. The is the file containing the public key. If that file doesn't also include the private key, you must indicate so using -pubin. The is the encrypted file name.

Now, to decrypt the file, you can simply flip the equation. Change -encrypt to -decrypt, and switch the input and output files.

Part 3 - Creating digital signatures

At last, we can produce a digital signature and verify it. Signing a large file directly with a public key algorithm is inefficient, so we should first compute the digest value of the information to be signed. This can be accomplished using the following command:

In this example, is whichever algorithm you choose to compute the digest value. The is the file containing the data you want to hash while 'digest' is the file that will contain the results of the hash application. This war of mine: the little ones crack.

The next step is to compute the signature of the digest value as follows:

Finally, you can check the validity of a signature like so:

Here, signature is the filename of your signature, and key.pem is the file with the public key. To confirm the verification for yourself, you can compute the digest value of the input file and compare it to the digest value produced from the verification of the digital signature.

Part 4 - Certificate signing requests

Let's say that you want to create digital certificates signed by your own certificate authority. Before you can get an SSL certificate from a certificate authority, or CA, you must first generate a certificate signing request or a CSR. A CSR includes a public key as well as some extra information that gets inserted into the certificate when signed.

When you first create a CSR, you'll be asked to supply some information about yourself or your organization. In the field 'Common Name,' or CN, you must provide the fully qualified domain name of the host for which the certificate is intended. If you're actually purchasing an SSL certificate from a CA, then the information you provide should be factual and accurate! Imagine you want to secure an Apache HTTP or Nginx web server with HTTPS. You can use the following snippet to create a new 2048-bit private key along with a CSR from scratch:

Imagine you want to secure an Apache HTTP or Nginx web server with HTTPS. You can use the following snippet to create a new 2048-bit private key along with a CSR from scratch:

Just replace 'domain' with your domain name. Here, the -newkey rsa:2048 option tells OpenSSL that it should use the RSA algorithm to create a 2048-bit key, and the -nodes option indicates that the key shouldn't be password protected.

After you've provided all of the necessary information, your CSR will be generated. Now, you can send it to a CA and request an SSL certificate. If your CA supports SHA-2, be sure to add the -sha256 option if you want your CSR to be signable with SHA-2.

To create a CSR for a private key that already exists, you would use this format:

Again, replace domain with your domain name. The -key option here indicates that you're using an existing private key while -new indicates that you're creating a new CSR. In the prior example, -new was implied because you were making a new key.

Let's say you already have a certificate that you want to renew, yet you somehow lost the original CSR. Don't panic; you can generate a new one based on information from your certificate and the private key. For example, if you were using an X509 certificate, you'd use the following code:

The -x509toreq option is needed to let OpenSSL know the certificate type.

Part 5 - Generating SSL certificates

If you desire the extra security of an SSL certificate, but you can't afford or don't want to be bothered with a CA, a less expensive alternative is to sign your own certificates. Self-signed certificates are signed with their own private keys, and they are just as effective at encrypting data as CA-signed certificates; however, users might receive an alert from their browser indicating that the connection is not secure, so self-signed certificates are really only recommended in environments where you're not required to prove your service's identity such as on a non-public server.

Again, assume that you're using HTTPS to secure an Apache HTTP or Nginx web server. The following command will create a 2048-bit private key along with a self-signed certificate:

The -x509 option tells OpenSSL that you want a self-signed certificate, while -days 365 indicates that the certificate should be valid for one year. OpenSSL will generate a temporary CSR for the purpose of gathering information to associate with the certificate, so you will have to answer the prompts per usual.

If you already have a private key that you want to associate with a self-signed certificate, just change the code slightly:

Remember that inclusion of the -new option is necessary since you are creating a new CSR from an existing key.

Part 6 - Viewing certificates

To view certificates and CSR files, you must decode them from the PEM format. Use the following command to view the contents of a CSR in plain text:

To view a certificate's content in plain text, use:

You can verify that a certificate was signed by a specific CA by plugging its name into the following code:

Summary

How To Use Openssl On Mac

In today's increasingly digital world, improving internet security is imperative to protect our own security. Many website databases contain treasure troves of information about visitors, and hackers are always learning new ways to navigate system vulnerabilities and exploit such data. That's why security protocols must continue to evolve. Stay informed to make sure you're providing adequate protection for your users.

Introduction

If you are a system and network administrator, you have the issue of having multiple web-based applications that you need to access from within your LAN, or at least, accessible by certain employees of your organization. Generally, if these web applications are using HTTPS, the certificates are self-signed which causes the browser to issue a warning message every time you try to access such web apps. It can be a bit frustrating to actually accept the wrong the certificate every time. Besides, this can be exploited by malicious insiders who might intercept HTTPS traffic and forge fake certificates.

When HTTPS web sites are public – that is, they are accessible by anyone in the world, the digital certificate must be signed by an independent third-party trusted Certificate Authority (CA), such as, VeriSign, DigiCert, GoDaddy, GlobalSign, etc. However, if your websites are only accessible within your local LAN, it might not be worth the cost to have digital certificates issued by those trusted CAs.

The best secure solution in such a case is to implement your own local Certificate Authority (CA), which will sign the certificates installed on your LAN's web servers. In this article, I will explain how you can implement such a procedure using the infamous OpenSSL tool – which can be installed on Linux, Mac, and Windows. And it comes pre-installed on Kali Linux. The demonstration below will be on Kali Linux distribution.

How Certificate Authority Works

A CA exists for one sole purpose, which is to testify that the 'public key' of a certain entity – technically called a subject – really belongs to that subject. Just like in the real-world we have ID cards issued by the government by which we trust that a person is really who they are claiming to be, a website's digital certificate signed by a trusted CA causes the web browser to trust the authenticity of that website. The browser is assured that it is communicating with the right website not with a fake one.

Openssl Create Key Pair

Certificate Authority and Digital Certificates are part of a cryptographic scheme known as Public Key Infrastructure (PKI) which utilizes a hybrid model of asymmetric and symmetric encryption, in addition to hashing functions, to guarantee data confidentiality, data integrity, and server authenticity. We can summarize the procedure as follows:

1. The server (website) generates a pair of asymmetric keys, one public and one private. The private is kept secure at the server's side and never exposed.
2. The public key is encapsulated in what is called Certificate Signing Request (CSR) and sent to the CA.
3. The CA signs the public key and generates a digital certificate. The digital certificate contains the server's public key, but this time, it is signed by the CA. The certificate is returned to the server.
4. When the client (a browser) connects to the server (website), it is presented with the certificate. The client is able to verify the signature issued by the CA; and thus, the client trusts the authenticity of the server.

It is important to mention here that in order for the CA to sign a CSR, it must already have generated its own pair of public and private keys. However, the CA public key is not signed by another CA, but rather, it is self-signed. In other words, the CA issues its own certificate and signs it locally with its own private key. CA certificates are always self-signed. The question now is, how can the browser trust the self-signed certificate of a CA? The answer is that it cannot trust it unless it is manually stored in the client's machine in a secure way. That is the reason why global CAs pay OS vendors to have their root certificates pre-installed before the OS is shipped to the customer. Every Operating System, like Windows, MacOS, Linux, etc., comes with a certificate store, or Keychain, that have the root certificates of major CAs. The browser uses that pre-installed CA's certificate to verify the signature of the server's certificate.

Thus, if you are now implementing your own CA, the self-signed root certificate will be installed manually on each workstation that needs to connect to one of your local web application. Then, you will issue a separate certificate – signed by your CA – for each web server. The remainder of this article will discuss these two tasks: generating CA root certificate, and generating a server's certificate which will be signed by the CA.

Generating the CA Root Certificate

The first thing you need to do in order to be a CA is to generate a self-signed root certificate with the value CA:TRUE. The presence of this value indicates that the certificate – and the associated private key – can actually issue and sign other certificates. Servers' certificates, on the other hand, have the value CA:FALSE in them, which indicates that they are not allowed to sign other certificates. The following steps outline how to generate that root certificate.

OpenSSL requires a certain directory structure in order to function properly. Basically, you need to create a directory that will be the main directory of the CA; then, you will create four subdirectories and two files.

The above commands create the directory /root/ca to be our main CA directory. Then, we created four subdirectories:

certs: it will contain our created certificates, *.crt.
crl: it will contain Certificate Revocation List (CRL).
newcerts: used by OpenSSL internally.
private: it will contain any generated private keys, *.key.

We also changed the permission of the private subdirectory so that only root can access it. Finally, we created two files, index.txt and serial. Each time a new certificate is created, OpenSSL writes an entry in index.txt. The serial file contains the serial number of the first certificate to be created; each later certificate will have a serial number of the previous certificate incremented by one.

OpenSSL comes with a template configuration file. And instead of creating a new configuration file, we will simply copy the template file into our CA directory (/root/ca). We will in later steps modify the file to reflect the changes we have made. However, all we need to do now is to copy the file:

The place of the configuration file (openssl.cnf) may change from OS to OS. In Kali Linux, it is located in /etc/ssl/.

Now, it is time to generate a pair of keys (public and private). The public will be issued in a digital certificate signed by the private key, hence, self-signed.

req: is a request subcommand; it is used to create a certificate signing request or simply a self-signed certificate.
-config openssl.cnf: tells OpenSSL which configuration file it should use.
-new: simply issues a new request.
-x509: generates a self-signed certificate with the X.509 structure. Omitting this option will generate a certificate signing request (CSR) instead.
-days 1825: this indicates the validity period in days; and in this case, it is 5 years.
-extensions v3_ca: extensions are additional attributes of the digital certificate. And in this case, the certificate is designated as a CA certificate; meaning, it can be used to issue (sign and verify) other certificates.
-keyout private/ca.key: this is the first output file, and it is the private key which will be stored in the private subdirectory with the extension: .key.
-out certs/ca.crt: this is the second output file, and it is the self-signed root certificate which will be stored in the certs subdirectory with the extension: .crt.

We now need to make few modifications to the configuration file so it points to the right CA certificate and private keys.

Open the file /root/ca/openssl.cnf in your favorite text editor, and edit the following lines as follows:

The dir parameter should point to the CA directory, while the certificate and private_key parameters should point to the CA certificate and private key, respectively, created in the previous step.

This step is not mandatory, but rather for you to check that everything is OK. You will check the created CA root certificate and make sure the values are correct.

x509: a subcommand to manage x.509 certificates. It will be used here to print out the CA certificate.
-noout: there is no output file. The actual output will be displayed on the terminal window.
-text: the certificate will be printed in a text format.

The certificate will be printed out. It is important to understand the following parameters:

Using Openssl To Create Keys For Mac Catalina

At this point, you need copy the file ca.crt and manually install it on your LAN's workstations. This is very crucial so that later servers' certificates will be verified automatically by the browsers.

Generating a Server's Certificate

After creating the CA's root certificate, you are now ready to issue a certificate for every website in your LAN. Those servers' certificates will be signed by the CA's private key; and they will be installed on their corresponding web servers.

Unlike the CA's root certificate that is self-signed, a server certificate needs to be signed by the CA; and as such, we need first to issue a Certificate Signing Request containing a newly-created public key (of the server).

req: is a request subcommand; it is used to create a certificate signing request or simply a self-signed certificate.
-config openssl.cnf: tells OpenSSL which configuration file it should use.
-new: simply issues a new request.
-nodes: the private key will not be encrypted.
-days 365: this indicates the validity period in days; and in this case, it is one year.
-keyout private/server.key: this is the first output file, and it is the RSA private key that will be stored securely on the web server.
-out server.csr: this is the CSR, and it is a temporary file; after it is signed in the next step and normal certificate is generated, it will be removed.

It is time now to sign the CSR:

The ca subcommand is used for various CA management tasks, one of which is signing CSRs. The policy argument states how the certificate attributes should look like; when policy_anything is used, attributes like Country Name, Organization Name, Email Address, etc., are optional.

The infiles argument takes the CSR file to be processed and the output will be a certificate (server.crt) stored in the certs subdirectory.

You can check the certificate and all its attributes using the following command – which is similar to the one we used when verifying the CA certificate:

Now you need to copy the two files certs/server.crt and private/server.key to the web server. Once correctly installed, any from your organization accessing the web server over HTTPS will be presented with the server's certificate, which will be verified by the browser using the CA certificate (pre-installed manually).