Generate self signed root certificate

Openssl is a handy utility to create self-signed certificates. You can use OpenSSL on all the operating systems such as Windows, MAC, and Linux flavors.

1. Introduction
2. Target Audience
3. About OpenSSL
4. Practical OpenSSL Usage
5. SSL Certificates
6. Configuring Apache for SSL Support
7. Resources

If you don’t have access to a certificate authority (CA) for your organization and want to use OpenSearch for non-demo purposes, you can generate your own self-signed certificates using OpenSSL.

You can probably find OpenSSL in the package manager for your operating system.

On CentOS, use Yum:

On macOS, use Homebrew:

This is an earlier version of the OpenSearch documentation. For the latest version, see the current documentation. For information about OpenSearch version maintenance, see Release Schedule and Maintenance Policy.

If you don’t have access to a certificate authority (CA) for your organization and want to use OpenSearch for non-demo purposes, you can generate your own self-signed certificates using OpenSSL.

You can probably find OpenSSL in the package manager for your operating system.

On CentOS, use Yum:

On macOS, use Homebrew:

This version of the OpenSearch documentation is no longer maintained. For the latest version, see the current documentation. For information about OpenSearch version maintenance, see Release Schedule and Maintenance Policy.

If you don’t have access to a certificate authority (CA) for your organization and want to use OpenSearch for non-demo purposes, you can generate your own self-signed certificates using OpenSSL.

You can probably find OpenSSL in the package manager for your operating system.

On CentOS, use Yum:

On macOS, use Homebrew:

One of the most common forms of cryptography today is public-key cryptography. Public-key cryptography utilizes a public key and a private key. The system works by encrypting information using the public key. The information can then only be decrypted using the private key.

A common use for public-key cryptography is encrypting application traffic using a Secure Socket Layer (SSL) or Transport Layer Security (TLS) connection. One example: configuring Apache to provide HTTPS, the HTTP protocol over SSL/TLS. This allows a way to encrypt traffic using a protocol that does not itself provide encryption.

A certificate is a method used to distribute a public key and other information about a server and the organization who is responsible for it. Certificates can be digitally signed by a Certification Authority, or CA. A CA is a trusted third party that has confirmed that the information contained in the certificate is accurate.

Generate a private key

The first step in this process is to generate a private key using the openssl genrsa command. As the name suggests, you should keep this file private.

Private keys must be of sufficient length to be secure, so specify 2048:

openssl genrsa  root-ca-key.pem 2048

You can optionally add the -aes256 option to encrypt the key using the AES-256 standard. This option requires a password.

Practical OpenSSL Usage

Installing OpenSSL Toolkit

Installing OpenSSL Library

libssl0.9.6 - SSL shared libraries (old version)
libssl-dev - SSL development libraries, header files and documentation
libssl0.9.7 - SSL shared libraries

Installing OpenSSL Development Library

Basic OpenSSL Commands

Determine installed OpenSSL version:

List of available OpenSSL sub-commands:

List all available cipher algorithms:

Анонс

В предыдущей статье «Сам себе PKI: Теория на примере Let’s Encrypt» мы рассмотрели теорию и разобрали пример, как происходит установка HTTPS соединения между браузером и веб-сайтом при использовании сертификатов Let’s Encrypt. В этой статье перейдем к практике и самостоятельно реализуем ту же самую схему: 

• Сначала вручную (с помощью OpenSSL) пройдем цепочку генерации и использования самоподписанных сертификатов в HTTPS сервере. 

• Далее развернем собственный удостоверяющий центр Smallstep и будем получать сертификаты, подписанные им.

Схема PKI остаётся той же, только изменяются компоненты:

• В качестве CA вместо Let’s Encrypt, будет использоваться OpenSSL и CA Smallstep.

• В роли Web-сервера вместо Интернет веб-сайта, будет выступать простой HTTPS сервер, запущенный на Node.js.

Generate an admin certificate

openssl genrsa  admin-key-temp.pem 2048

Then convert that key to PKCS#8 format for use in Java using a PKCS#12-compatible algorithm (3DES):

openssl pkcs8  PEM  PEM  admin-key-temp.pem    PBE-SHA1-3DES  admin-key.pem

Next, create a certificate signing request (CSR). This file acts as an application to a CA for a signed certificate:

openssl req   admin-key.pem  admin.csr

If you generate TLS certificates and have enabled hostname verification by setting plugins.security.ssl.transport.enforce_hostname_verification to true (default), be sure to specify a common name (CN) for each certificate signing request (CSR) that matches the corresponding DNS A record of the intended node.

Now that the private key and signing request have been created, generate the certificate:

openssl x509   admin.csr  root-ca.pem  root-ca-key.pem    admin.pem  730

Just like the root certificate, use the -days option to specify an expiration date of longer than 30 days.

Add distinguished names to opensearch. yml

But if you look at the subject of the certificate after creating it, you might see different formatting:

subject=/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=node1.dns.a-record

If you compare this string to the ones above, you can see that you need to invert the order of elements and use commas rather than slashes. Enter this command to get the correct string:

openssl x509   RFC2253   node.pem

Then copy and paste the output into opensearch.yml.

(Optional) Generate node and client certificates

To generate a node or client certificate, first create a new key:

openssl genrsa  node1-key-temp.pem 2048

Then convert that key to PKCS#8 format for use in Java using a PKCS#12-compatible algorithm (3DES):

openssl pkcs8  PEM  PEM  node1-key-temp.pem    PBE-SHA1-3DES  node1-key.pem

Next, create the CSR:

openssl req   node1-key.pem  node1.csr

For all host and client certificates, you should specify a subject alternative name (SAN) to ensure compliance with RFC 2818 (HTTP Over TLS). The SAN should match the corresponding CN so that both refer to the same DNS A record.

Before generating a signed certificate, create a SAN extension file which describes the DNS A record for the host:

   node1.ext

Generate the certificate:

openssl x509   node1.csr  root-ca.pem  root-ca-key.pem    node1.pem  730  node1.ext

What are the drawbacks of using a self-signed certificate?

There are also several drawbacks of using a self-signed certificate:

1. Your users will need to install the certificate in their browsers or applications.
2. Your users will need to trust your certificate authority manually.
3. They unsafe for public facing applications.
4. None of the browsers or operating systems trust the self-signed certificates unless the user installs them.
5. Prone to man-in-the-middle attacks.

In general, self-signed certificates are a good option for applications in which you need to prove your own identity. They’re also a good option for development and testing environments. However, they shouldn’t be used for production applications.

(Optional) Generate node and client certificates

To generate a node or client certificate, first create a new key:

openssl genrsa  node1-key-temp.pem 2048

Then convert that key to PKCS#8 format for use in Java using a PKCS#12-compatible algorithm (3DES):

openssl pkcs8  PEM  PEM  node1-key-temp.pem    PBE-SHA1-3DES  node1-key.pem

Next, create the CSR:

openssl req   node1-key.pem  node1.csr

For all host and client certificates, you should specify a subject alternative name (SAN) to ensure compliance with RFC 2818 (HTTP Over TLS). The SAN should match the corresponding CN so that both refer to the same DNS A record.

Before generating a signed certificate, create a SAN extension file which describes the DNS A record for the host:

   node1.ext

Generate the certificate:

openssl x509   node1.csr  root-ca.pem  root-ca-key.pem    node1.pem  730  node1.ext

OpenSearch Dashboards

For information on using your root CA and a client certificate to enable TLS for OpenSearch Dashboards, see Configure TLS for OpenSearch Dashboards.

Sample script

# Root CA
openssl genrsa  root-ca-key.pem 2048
openssl req     root-ca-key.pem    root-ca.pem  730

openssl genrsa  admin-key-temp.pem 2048
openssl pkcs8  PEM  PEM  admin-key-temp.pem    PBE-SHA1-3DES  admin-key.pem
openssl req   admin-key.pem    admin.csr
openssl x509   admin.csr  root-ca.pem  root-ca-key.pem    admin.pem  730
# Node cert 1
openssl genrsa  node1-key-temp.pem 2048
openssl pkcs8  PEM  PEM  node1-key-temp.pem    PBE-SHA1-3DES  node1-key.pem
openssl req   node1-key.pem    node1.csr
   node1.ext
openssl x509   node1.csr  root-ca.pem  root-ca-key.pem    node1.pem  730  node1.ext
# Node cert 2
openssl genrsa  node2-key-temp.pem 2048
openssl pkcs8  PEM  PEM  node2-key-temp.pem    PBE-SHA1-3DES  node2-key.pem
openssl req   node2-key.pem    node2.csr
   node2.ext
openssl x509   node2.csr  root-ca.pem  root-ca-key.pem    node2.pem  730  node2.ext
# Client cert
openssl genrsa  client-key-temp.pem 2048
openssl pkcs8  PEM  PEM  client-key-temp.pem    PBE-SHA1-3DES  client-key.pem
openssl req   client-key.pem    client.csr
   client.ext
openssl x509   client.csr  root-ca.pem  root-ca-key.pem    client.pem  730  client.ext

admin-key-temp.pem
admin.csr
node1-key-temp.pem
node1.csr
node1.ext
node2-key-temp.pem
node2.csr
node2.ext
client-key-temp.pem
client.csr
client.ext

Add certificate files to opensearch. yml

This process generates many files, but these are the ones you need to add to each node:

• root-ca.pem
• admin.pem
• admin-key.pem
• (Optional) node1.pem
• (Optional) node1-key.pem

On one node, the security configuration portion of opensearch.yml might look like this:

Shell Script To Create Self-Signed Certificate

#! /bin/bash

if [ "$#" -ne 1 ]
then
  echo "Error: No domain name argument provided"
  echo "Usage: Provide a domain name as an argument"
  exit 1
fi

DOMAIN=$1

# Create root CA & Private key

openssl req -x509 \
            -sha256 -days 356 \
            -nodes \
            -newkey rsa:2048 \
            -subj "/CN=${DOMAIN}/C=US/L=San Fransisco" \
            -keyout rootCA.key -out rootCA.crt 

# Generate Private key 

openssl genrsa -out ${DOMAIN}.key 2048

# Create csf conf

cat > csr.conf <<EOF
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[ dn ]
C = US
ST = California
L = San Fransisco
O = MLopsHub
OU = MlopsHub Dev
CN = ${DOMAIN}

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = ${DOMAIN}
DNS.2 = www.${DOMAIN}
IP.1 = 192.168.1.5 
IP.2 = 192.168.1.6

EOF

# create CSR request using private key

openssl req -new -key ${DOMAIN}.key -out ${DOMAIN}.csr -config csr.conf

# Create a external config file for the certificate

cat > cert.conf <<EOF

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = ${DOMAIN}

EOF

# Create SSl with self signed CA

openssl x509 -req \
    -in ${DOMAIN}.csr \
    -CA rootCA.crt -CAkey rootCA.key \
    -CAcreateserial -out ${DOMAIN}.crt \
    -days 365 \
    -sha256 -extfile cert.conf

chmod +x ssl.sh

Execute the script with the domain name or IP. For example,

./ssl.sh demo.mlopshub.com

The script will create all the certificates and keys we created using the individual commands. The SSL certificate and private keys get named with the domain name you pass as the script argument. For example, demo.mlopshub.com.key & demo.mlopshub.com.crt

(Optional) Generate node and client certificates

To generate a node or client certificate, first create a new key:

openssl genrsa  node1-key-temp.pem 2048

Then convert that key to PKCS#8 format for use in Java using a PKCS#12-compatible algorithm (3DES):

openssl pkcs8  PEM  PEM  node1-key-temp.pem    PBE-SHA1-3DES  node1-key.pem

Next, create the CSR:

openssl req   node1-key.pem  node1.csr

For all host and client certificates, you should specify a subject alternative name (SAN) to ensure compliance with RFC 2818 (HTTP Over TLS). The SAN should match the corresponding CN so that both refer to the same DNS A record.

Before generating a signed certificate, create a SAN extension file which describes the DNS A record for the host:

   node1.ext

Generate the certificate:

openssl x509   node1.csr  root-ca.pem  root-ca-key.pem    node1.pem  730  node1.ext

Generate an admin certificate

openssl genrsa  admin-key-temp.pem 2048

Then convert that key to PKCS#8 format for use in Java using a PKCS#12-compatible algorithm (3DES):

openssl pkcs8  PEM  PEM  admin-key-temp.pem    PBE-SHA1-3DES  admin-key.pem

Next, create a certificate signing request (CSR). This file acts as an application to a CA for a signed certificate:

openssl req   admin-key.pem  admin.csr

If you generate TLS certificates and have enabled hostname verification by setting plugins.security.ssl.transport.enforce_hostname_verification to true (default), be sure to specify a common name (CN) for each certificate signing request (CSR) that matches the corresponding DNS A record of the intended node.

Now that the private key and signing request have been created, generate the certificate:

openssl x509   admin.csr  root-ca.pem  root-ca-key.pem    admin.pem  730

Just like the root certificate, use the -days option to specify an expiration date of longer than 30 days.

Add certificate files to opensearch. yml

This process generates many files, but these are the ones you need to add to each node:

• root-ca.pem
• admin.pem
• admin-key.pem
• (Optional) node1.pem
• (Optional) node1-key.pem

On one node, the security configuration portion of opensearch.yml might look like this:

Generating a Certificate Signing Request (CSR)

Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key.

If the certificate will be used by service daemons, such as Apache, Postfix, Dovecot, etc., a key without a passphrase is often appropriate. Not having a passphrase allows the services to start without manual intervention, usually the preferred way to start a daemon.

This section will cover generating a key with a passphrase, and one without. The non-passphrase key will then be used to generate a certificate that can be used with various service daemons.

Running your secure service without a passphrase is convenient because you will not need to enter the passphrase every time you start your secure service. But it is insecure and a compromise of the key means a compromise of the server as well.

openssl genrsa -des3 -out server.key 2048

Generating RSA private key, 2048 bit long modulus
..........................++++++
.......++++++
e is 65537 (0x10001)
Enter pass phrase for server.key:

You can now enter your passphrase. For best security, it should at least contain eight characters. The minimum length when specifying -des3 is four characters. As a best practice it should include numbers and/or punctuation and not be a word in a dictionary. Also remember that your passphrase is case-sensitive.

Re-type the passphrase to verify. Once you have re-typed it correctly, the server key is generated and stored in the server.key file.

Now create the insecure key, the one without a passphrase, and shuffle the key names:

openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key

The insecure key is now named server.key, and you can use this file to generate the CSR without passphrase.

openssl req -new -key server.key -out server.csr

It will prompt you enter the passphrase. If you enter the correct passphrase, it will prompt you to enter Company Name, Site Name, Email Id, etc. Once you enter all these details, your CSR will be created and it will be stored in the server.csr file.

You can now submit this CSR file to a CA for processing. The CA will use this CSR file and issue the certificate. On the other hand, you can create self-signed certificate using this CSR.

Self-Signed Certificate FAQ’s

How to create self-signed certificated on Windows?

How do I get a self-signed certificate?

Self-signed certificate can be generated by you using tools like openSSL or CDSSL PKI toolkit.

Resources

Additional resources pertaining to OpenSSL and Secure Sockets Layer appear below.

Local System Resources

WWW Resources

CACert, a FREE X.509 Certificate Authority

Public Key Infrastructure (X.509) (pkix)

CategorySecurity CategorySecurity CategorySecurity

Add distinguished names to opensearch. yml

But if you look at the subject of the certificate after creating it, you might see different formatting:

subject=/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=node1.dns.a-record

If you compare this string to the ones above, you can see that you need to invert the order of elements and use commas rather than slashes. Enter this command to get the correct string:

openssl x509   RFC2253   node.pem

Then copy and paste the output into opensearch.yml.

About OpenSSL

Secure Sockets Layer is an application-level protocol which was developed by the Netscape Corporation for the purpose of transmitting sensitive information, such as Credit Card details, via the Internet. SSL works by using a private key to encrypt data transferred over the SSL-enabled connection, thus thwarting eavesdropping of the information. The most popular use of SSL is in conjunction with web browsing (using the HTTP protocol), but many network applications can benefit from using SSL. By convention, URLs that require an SSL connection start with https: instead of http:.

OpenSSL is a robust, commercial-grade implementation of SSL tools, and related general purpose library based upon SSLeay, developed by Eric A. Young and Tim J. Hudson. OpenSSL is available as an Open Source equivalent to commercial implementations of SSL via an Apache-style license.

About X.509

Generate a root certificate

Next, use the private key to generate a self-signed certificate for the root CA:

openssl req     root-ca-key.pem  root-ca.pem  730

The default -days value of 30 is only useful for testing purposes. This sample command specifies 730 (two years) for the certificate expiration date, but use whatever value makes sense for your organization.

• The -x509 option specifies that you want a self-signed certificate rather than a certificate request.
• The -sha256 option sets the hash algorithm to SHA-256. SHA-256 is the default in later versions of OpenSSL, but earlier versions might use SHA-1.

Types of Certificates

To set up a secure server using public-key cryptography, in most cases, you send your certificate request (including your public key), proof of your company’s identity, and payment to a CA. The CA verifies the certificate request and your identity, and then sends back a certificate for your secure server. Alternatively, you can create your own self-signed certificate.

Note that self-signed certificates should not be used in most production environments.

Continuing the HTTPS example, a CA-signed certificate provides two important capabilities that a self-signed certificate does not:

• When a CA issues a signed certificate, it is guaranteeing the identity of the organization that is providing the web pages to the browser.

1. Create a private and public encryption key pair.

2. Create a certificate signing request based on the public key. The certificate request contains information about your server and the company hosting it.

3. Send the certificate request, along with documents proving your identity, to a CA. We cannot tell you which certificate authority to choose. Your decision may be based on your past experiences, or on the experiences of your friends or colleagues, or purely on monetary factors.

4. When the CA is satisfied that you are indeed who you claim to be, they send you a digital certificate.

5. Install this certificate on your secure server, and configure the appropriate applications to use the certificate.

Generate a root certificate

Next, use the private key to generate a self-signed certificate for the root CA:

openssl req     root-ca-key.pem  root-ca.pem  730

The default -days value of 30 is only useful for testing purposes. This sample command specifies 730 (two years) for the certificate expiration date, but use whatever value makes sense for your organization.

• The -x509 option specifies that you want a self-signed certificate rather than a certificate request.
• The -sha256 option sets the hash algorithm to SHA-256. SHA-256 is the default in later versions of OpenSSL, but earlier versions might use SHA-1.

Sample script

# Root CA
openssl genrsa  root-ca-key.pem 2048
openssl req     root-ca-key.pem    root-ca.pem  730

openssl genrsa  admin-key-temp.pem 2048
openssl pkcs8  PEM  PEM  admin-key-temp.pem    PBE-SHA1-3DES  admin-key.pem
openssl req   admin-key.pem    admin.csr
openssl x509   admin.csr  root-ca.pem  root-ca-key.pem    admin.pem  730
# Node cert 1
openssl genrsa  node1-key-temp.pem 2048
openssl pkcs8  PEM  PEM  node1-key-temp.pem    PBE-SHA1-3DES  node1-key.pem
openssl req   node1-key.pem    node1.csr
   node1.ext
openssl x509   node1.csr  root-ca.pem  root-ca-key.pem    node1.pem  730  node1.ext
# Node cert 2
openssl genrsa  node2-key-temp.pem 2048
openssl pkcs8  PEM  PEM  node2-key-temp.pem    PBE-SHA1-3DES  node2-key.pem
openssl req   node2-key.pem    node2.csr
   node2.ext
openssl x509   node2.csr  root-ca.pem  root-ca-key.pem    node2.pem  730  node2.ext
# Client cert
openssl genrsa  client-key-temp.pem 2048
openssl pkcs8  PEM  PEM  client-key-temp.pem    PBE-SHA1-3DES  client-key.pem
openssl req   client-key.pem    client.csr
   client.ext
openssl x509   client.csr  root-ca.pem  root-ca-key.pem    client.pem  730  client.ext

admin-key-temp.pem
admin.csr
node1-key-temp.pem
node1.csr
node1.ext
node2-key-temp.pem
node2.csr
node2.ext
client-key-temp.pem
client.csr
client.ext

Generate a private key

The first step in this process is to generate a private key using the openssl genrsa command. As the name suggests, you should keep this file private.

Private keys must be of sufficient length to be secure, so specify 2048:

openssl genrsa  root-ca-key.pem 2048

You can optionally add the -aes256 option to encrypt the key using the AES-256 standard. This option requires a password.

Installing the Certificate

sudo cp server.crt /etc/ssl/certs
sudo cp server.key /etc/ssl/private

Now simply configure any applications, with the ability to use public-key cryptography, to use the certificate and key files. For example, Apache can provide HTTPS, Dovecot can provide IMAPS and POP3S, etc.

Generate a private key

The first step in this process is to generate a private key using the openssl genrsa command. As the name suggests, you should keep this file private.

Private keys must be of sufficient length to be secure, so specify 2048:

openssl genrsa  root-ca-key.pem 2048

You can optionally add the -aes256 option to encrypt the key using the AES-256 standard. This option requires a password.

Практика Self-signed certificate

OpenSSL 

Начнем с классики криптографии OpenSSL. Сейчас широко используется версия 1.1.1, но ее поддержка заканчивается в 2023. Следующая версия 3.0 будет поддерживаться до 2026 года. Проверка установленной версии:

OpenSSL 1.1.1k FIPS 25 Mar 2021

Если OpenSSL не установлен, то его можно установить на всех востребованных платформах.

Реализация TLS

• Для нашего CA генерируем приватный ключ 2048-бит RSA. Администратор CA должен хранить его в секрете от всех: 

openssl genrsa -out root_ca.key 2048

• Далее для нашего CA генерируем X.509 сертификат на 365 дней (root_ca.crt) и подписываем его приватным ключом (root_ca.key). Получается самоподписанный сертификат, его можно и нужно будет скопировать на все компьютеры, между которыми необходимо организовать TLS соединение. При ответах на вопросы, которые будет задавать OpenSSL, можно указывать произвольные данные, CA я назвал «My CN»: 

openssl req -x509 -new -key root_ca.key -days 365 -out root_ca.crt

• Смотрим получившийся сертификат, убеждаемся, что данные в нем корректные:

openssl x509 -text -in root_ca.crt

• Генерируем приватный ключ для HTTPS сервера, его нужно будет скопировать только на компьютер, на котором он будет работать и никуда больше:

openssl genrsa -out server.key 2048

openssl req -new -key server.key -subj "/CN=xx.xx.xx.xx/CN=server/CN=server.example.com" -out server.csr

• Можно посмотреть получившийся запрос на сертификат и убедиться в его корректности:

openssl req -text -in server.csr

• Теперь генерируем сертификат X.509 (server.crt) на 365 дней для HTTPS сервера и подписываем его приватным ключом CA (root_ca.key):

openssl x509 -req -in server.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out server.crt -days 365 -extensions SAN -extfile openssl.cnf

• Файл openssl.cnf должен содержать список SAN (Subject Alternative Name) идентичный тому, что был в CSR запросе на сертификат:

[SAN]
subjectAltName = @alt_names
[alt_names]
IP.1 = xx.xx.xx.xx
DNS.1 = server
DNS.2 = server.example.com

• Можно посмотреть на получившийся сертификат и убедиться в его корректности:

openssl x509 -text -in root_ca.crt

• С ключами и сертификатами закончили, переходим к запуску HTTPS сервера. Копируем следующие файлы на компьютер, на котором будет работать HTTPS сервер: 

• Пишем простейший HTTPS сервер, на JS:

const fs = require('fs');
const https = require('https');
 
https
  .createServer(
    {
      requestCert: false,
      rejectUnauthorized: false,
      ca: fs.readFileSync('root_ca.crt'),
      cert: fs.readFileSync('server.crt'),
      key: fs.readFileSync('server.key')
    },
    (req, res) => {
      console.log("req.client.authorized: ", req.client.authorized)
      if (req.client.authorized) {
        const cert = req.socket.getPeerCertificate(false) // true - получить все сертификаты, false - последний
        console.log("cert: ", cert)
    }
      res.end('Hello, world!');
    }
  )
  .listen(9443);

• Запускать данный скрипт будем с помощью Node.js. Если Node.js не установлен, то устанавливаем:

sudo yum groupinstall 'Development Tools'

sudo yum install nodejs

• Проверяем, что Node и Npm установились успешно:

• Проверяем сервер curl-ом:

При первом запросе возникнет ошибка: 

curl: (60) SSL certificate problem: self signed certificate in certificate chain

Это значит, что самоподписанный корневой сертификат нашего CA (root_ca.crt) не находится в хранилище доверительных сертификатов. Процесс загрузки сертификатов в это хранилище специфичен для операционной системы. Приведу алгоритм для RH Linux:

• Если сертификат не в PEM (текстовом) формате, то его надо сконвертировать в текстовой формат:

openssl x509 -in root_ca.crt -out root_ca.pem -outform PEM

• Копируем сертификат в определенный каталог на сервере. ДляRH 7 и выше это каталог:

• Выполняем команду обновления хранилища сертификатов:

• Теперь curl проходит 

• на Windows есть специфика — в curl необходимо добавлять параметр «ssl-no-revoke», чтобы не проверялся список отозванных сертификатов:

• При этом сервер выведет в консоль строку:

Это значит, что мы установили TLS соединение только с проверкой сертификата сервера, а не клиента. Переходим к mTLS.

Реализация mTLS 

В коде сервера включаем mTLS, а именно выставляем в true параметр requestCert, чтобы HTTPS сервер запрашивал клиентский сертификат и параметр rejectUnauthorized, чтобы сервер отклонял запросы клиентов, которые не прошли авторизацию:

{
requestCert: true,
rejectUnauthorized: true,
}

Алгоритм генерации клиентских сертификатов аналогичен серверным.

• Генерируем приватный ключ для клиента:

openssl genrsa -out client.key 2048

• Генерируем запрос на сертификат CSR со списком CN:

openssl req -new -key client.key -subj "/CN=xx.xx.xx.xx/CN=client/CN=client.example.com" -out client.csr

• Генерируем сертификат для клиента и подписываем его приватным ключом CA:

openssl x509 -req -in client.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out client.crt -days 365 -extensions SAN -extfile openssl.cnf

Файл openssl.cnf — такой же как и для сервера, только вместо «server» пишем «client». 

• Копируем следующие файлы на компьютер, на котором будет работать клиент: 

• Теперь если просто вызвать curl:

• То произойдет ошибка авторизации

curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

• Поэтому вызываем curl с дополнительными параметрами, в которых указываем ключ клиента и сертификаты клиента и СА: 

curl --cert ./client.crt --key client.key --cacert root_ca.crt https://server.example.com:9443

• Теперь запрос проходит, при этом сервер выведет в консоль следующую строку и далее содержимое полученного от клиента сертификата:

Это значит, что мы установили mTLS соединение с проверкой сертификата как сервера, так и клиента. Теперь установим mTLS из браузера.

Реализация mTLS в браузере 

Если просто запустить наш запрос к серверу (https://server.example.com:9443) из браузера, то выдается ошибка клиентского сертификата ERR_BAD_SSL_CLIENT_AUTH_CERT. Рабочие адреса закрасил желтым:

Для загрузки в браузер клиентский сертификат и приватный ключ надо сконвертировать в формат p12. Этот формат определяется стандартом PKCS #12 и является архивом для хранения нескольких объектов. В нашем случае файл будет хранить клиентский сертификат и его приватный ключ. Понятно, что приватный ключ — это чувствительная к разглашению информация и ее владелец не должен выкладывать p12 сертификат в открытый доступ. Для конвертации тоже используем OpenSSL:

openssl pkcs12 -inkey client.key -in client.crt -export -out client.p12

Импортируем client.p12 в браузер. Для этого, например в Chrome, идем в меню: Settings / Privacy and security / Manage certificates, в открывшемся окне нажимаем Import, выбираем наш файл client.p12 и место хранения «Personal». Видим, что клиентский сертификат, выданный нашим удостоверяющим центром «My CN», появился  в хранилище персональных сертификатов:

Вызываем запрос заново, уже лучше, но браузер все равно пишет, что соединение не безопасно. Это из-за того, что клиентский сертификат выдан удостоверяющим центром «My CN», которого нет в списке доверительных CA (Trusted Root Certification Authorities). 

Добавляем корневой сертификат нашего CA (root_ca.crt) в Trusted Root Certification Authorities. Делается с помощью того же вызова Import, что и для клиентского сертификата, но хранилище указываем Trusted Root Certification Authorities. Проверяем, что наш CA «My CN» появился в хранилище:

Повторяем наш запрос (https://server.example.com:9443). При первом запросе браузер находит подходящий клиентский сертификат и просит явно подтвердить его использование:

Дальнейшие вызовы проходят без запросов на подтверждение клиентского сертификата:

Если щелкнуть на замочке а адресной строке, то можно посмотреть сертификат сервера и убедиться, что мы взаимодействуем с правильным сервером (Issued to: server.example.com), сертификат которому выдан нашим удостоверяющим центром (Issued by: My CN) и время действия сертификата еще не прошло (Valid to: 31.05.2023):

Таким образом мы организовали mTLS соединение из браузера. Далее приведу для справки несколько дополнительных возможностей OpenSSL, которые могут пригодиться в процессе работы. 

Дополнительные возможности OpenSSL

Конвертация форматов сертификатов

• Конвертируем сертификат в der (бинарный формат):

openssl x509 -outform der -in client.crt -out client.der

• Конвертируем сертификат в PEM (текстовой формат)

openssl x509 -inform der -in client.cer -out client.pem

Отладка с помощью OpenSSL

• Проверка, что сертификат подписан определенным (root_ca.pem) удостоверяющим центром:

openssl verify -verbose -x509_strict -CAfile root_ca.pem server.crt

openssl s_server -accept 9443 -cert server.crt -key server.key

• Запускаем OpenSSL client

openssl s_client -connect xx.xx.xx.xx:9443 -prexit -showcerts -state -status -tlsextdebug -verify 10 

• При вызове curl параметр:

  • -k — позволяет подсоединяться к серверу без проверки цепочки сертификатов (certificate path validation). 

  • —ssl-no-revoke  — предотвращает проверку отозванных сертификатов 

Generate an admin certificate

openssl genrsa  admin-key-temp.pem 2048

Then convert that key to PKCS#8 format for use in Java using a PKCS#12-compatible algorithm (3DES):

openssl pkcs8  PEM  PEM  admin-key-temp.pem    PBE-SHA1-3DES  admin-key.pem

Next, create a certificate signing request (CSR). This file acts as an application to a CA for a signed certificate:

openssl req   admin-key.pem  admin.csr

If you generate TLS certificates and have enabled hostname verification by setting plugins.security.ssl.transport.enforce_hostname_verification to true (default), be sure to specify a common name (CN) for each certificate signing request (CSR) that matches the corresponding DNS A record of the intended node.

Now that the private key and signing request have been created, generate the certificate:

openssl x509   admin.csr  root-ca.pem  root-ca-key.pem    admin.pem  730

Just like the root certificate, use the -days option to specify an expiration date of longer than 30 days.

What are the benefits of using a self-signed certificate?

There are several benefits of using a self-signed certificate:

1. You don’t need to rely on a third party to sign your certificate.
2. You can create and use your own certificate authority.
3. You don’t have to pay for a certificate from a CA.
4. You have more control over your certificates.

Creating a Self-Signed Certificate

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

The above command will prompt you to enter the passphrase. Once you enter the correct passphrase, your certificate will be created and it will be stored in the server.crt file.

If your secure server is to be used in a production environment, you probably need a CA-signed certificate. It is not recommended to use self-signed certificate.

What is a Self Signed Certificate?

A self-signed certificate is an SSL/TSL certificate not signed by a public or private certificate authority. Instead, it is signed by the creator’s own personal or root CA certificate.

Here is what we do to request paid SSL/TLS certificate from a well-known Certificate Authority like Verisign or comodo.

1. Create a certificate signing request (CSR) with a private key. A CSR contains details about location, organization, and FQDN (Fully Qualified Domain Name).
2. Send the CSR to the trusted CA authority.
3. The CA authority will send you the SSL certificate signed by their root certificate authority and private key.
4. You can then validate and use the SSL certificate with your applications.

But for a self-signed certificate, here is what we do.

1. Create our own root CA certificate & CA private key (We act as a CA on our own)
2. Create a server private key to generate CSR
3. Create an SSL certificate with CSR using our root CA and CA private key.
4. Install the CA certificate in the browser or Operating system to avoid security warnings.

Most browsers & operating systems hold a copy of root CA certificates of all the trusted certified Certificated Authorities. That’s the reason the browsers won’t show any security messages when you visit standard websites that use SSL from a trusted and well-known commercial Certificate authority.

At the same time, if you use a self-signed certificate, your browser will throw a security warning. The reason is browsers only trust SSL from a trusted Certificate authority. For example,

Your connection is not private
Attackers might be trying to steal your information from demo.apps.mlopshub.com (for example, passwords, messages or credit cards)

Also, you can use this CA to create more than one SSL certificate.

Self-Signed Certificates in Organizations

Many organizations use self-signed certificated for their internal applications that are not internet-facing. These certificates are generated using the organization’s internal PKI infrastructure.

DevOps teams and developers can request SSL certificates from the PKI infrastructure to be used in applications.

Generate a root certificate

Next, use the private key to generate a self-signed certificate for the root CA:

openssl req     root-ca-key.pem  root-ca.pem  730

The default -days value of 30 is only useful for testing purposes. This sample command specifies 730 (two years) for the certificate expiration date, but use whatever value makes sense for your organization.

• The -x509 option specifies that you want a self-signed certificate rather than a certificate request.
• The -sha256 option sets the hash algorithm to SHA-256. SHA-256 is the default in later versions of OpenSSL, but earlier versions might use SHA-1.

Add distinguished names to opensearch. yml

But if you look at the subject of the certificate after creating it, you might see different formatting:

subject=/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=node1.dns.a-record

If you compare this string to the ones above, you can see that you need to invert the order of elements and use commas rather than slashes. Enter this command to get the correct string:

openssl x509   RFC2253   node.pem

Then copy and paste the output into opensearch.yml.

OpenSearch Dashboards

For information on using your root CA and a client certificate to enable TLS for OpenSearch Dashboards, see Configure TLS for OpenSearch Dashboards.

Sample script

# Root CA
openssl genrsa  root-ca-key.pem 2048
openssl req     root-ca-key.pem    root-ca.pem  730

openssl genrsa  admin-key-temp.pem 2048
openssl pkcs8  PEM  PEM  admin-key-temp.pem    PBE-SHA1-3DES  admin-key.pem
openssl req   admin-key.pem    admin.csr
openssl x509   admin.csr  root-ca.pem  root-ca-key.pem    admin.pem  730
# Node cert 1
openssl genrsa  node1-key-temp.pem 2048
openssl pkcs8  PEM  PEM  node1-key-temp.pem    PBE-SHA1-3DES  node1-key.pem
openssl req   node1-key.pem    node1.csr
   node1.ext
openssl x509   node1.csr  root-ca.pem  root-ca-key.pem    node1.pem  730  node1.ext
# Node cert 2
openssl genrsa  node2-key-temp.pem 2048
openssl pkcs8  PEM  PEM  node2-key-temp.pem    PBE-SHA1-3DES  node2-key.pem
openssl req   node2-key.pem    node2.csr
   node2.ext
openssl x509   node2.csr  root-ca.pem  root-ca-key.pem    node2.pem  730  node2.ext
# Client cert
openssl genrsa  client-key-temp.pem 2048
openssl pkcs8  PEM  PEM  client-key-temp.pem    PBE-SHA1-3DES  client-key.pem
openssl req   client-key.pem    client.csr
   client.ext
openssl x509   client.csr  root-ca.pem  root-ca-key.pem    client.pem  730  client.ext

admin-key-temp.pem
admin.csr
node1-key-temp.pem
node1.csr
node1.ext
node2-key-temp.pem
node2.csr
node2.ext
client-key-temp.pem
client.csr
client.ext

OpenSearch Dashboards

For information on using your root CA and a client certificate to enable TLS for OpenSearch Dashboards, see Configure TLS for OpenSearch Dashboards.

SSL Certificates

SSL Certificates for Server Use

Once you have properly generated an X.509-compliant SSL certificate, you may either elect to sign the certificate yourself, by generating a Certificate Authority (CA), or you may opt to have a globally recognized Certificate Authority sign the certificate. When the certificate is signed, it is then ready to be used with the OpenSSL toolkit, or the library to enable encrypted SSL connections to a Lightweight Directory Access Protocol, (LDAP) or Hyper Text Transport Protocol (HTTP) server, for example. This section of the guide describes the certificate generation, and signing process for both self-signed, and recognized CA-signed certificates.

Generating and Signing Self-Signed Certificates

NOTE: You must obtain a certificate signed by a recognized Certificate Authority in order to establish a commercial site, e.g., for conducting «e-commerce».

cd && mkdir -p myCA/signedcerts && mkdir myCA/private && cd myCA

The above command will place you in a newly-created subdirectory of your home directory named myCA, and within this subdirectory, you should have two additional subdirectories named signedcerts and private.

• ~/myCA : contains CA certificate, certificates database, generated certificates, keys, and requests

• ~/myCA/signedcerts : contains copies of each signed certificate

• ~/myCA/private : contains the private key

sudo nano ~/myCA/caconfig.cnf

# My sample caconfig.cnf file.
#
# Default configuration to use when one is not provided on the command line.
#
[ ca ]
default_ca      = local_ca
#
#
# Default location of directories and files needed to generate certificates.
#
[ local_ca ]
dir             = /home/<username>/myCA
certificate     = $dir/cacert.pem
database        = $dir/index.txt
new_certs_dir   = $dir/signedcerts
private_key     = $dir/private/cakey.pem
serial          = $dir/serial
#       
#
# Default expiration and encryption policies for certificates.
#
default_crl_days        = 365
default_days            = 1825
default_md              = sha1
#       
policy          = local_ca_policy
x509_extensions = local_ca_extensions
#
#
# Copy extensions specified in the certificate request
#
copy_extensions = copy
#       
#
# Default policy to use when generating server certificates.  The following
# fields must be defined in the server certificate.
#
[ local_ca_policy ]
commonName              = supplied
stateOrProvinceName     = supplied
countryName             = supplied
emailAddress            = supplied
organizationName        = supplied
organizationalUnitName  = supplied
#       
#
# x509 extensions to use when generating server certificates.
#
[ local_ca_extensions ]
basicConstraints        = CA:false
#       
#
# The default root certificate generation policy.
#
[ req ]
default_bits    = 2048
default_keyfile = /home/<username>/myCA/private/cakey.pem
default_md      = sha1
#       
prompt                  = no
distinguished_name      = root_ca_distinguished_name
x509_extensions         = root_ca_extensions
#
#
# Root Certificate Authority distinguished name.  Change these fields to match
# your local environment!
#
[ root_ca_distinguished_name ]
commonName              = MyOwn Root Certificate Authority
stateOrProvinceName     = NC
countryName             = US
emailAddress            = root@tradeshowhell.com
organizationName        = Trade Show Hell
organizationalUnitName  = IT Department
#       
[ root_ca_extensions ]
basicConstraints        = CA:true

When you’ve edited the file to match your environment, save the file as ~/myCA/caconfig.cnf.

Next, you need to generate the Certificate Authority Root Certificate and Key, by issuing a few commands. First, do this:

export OPENSSL_CONF=~/myCA/caconfig.cnf

The previous command sets an environment variable, OPENSSL_CONF, which forces the openssl tool to look for a configuration file in an alternative location (in this case, ~/myCA/caconfig.cnf).

openssl req -x509 -newkey rsa:2048 -out cacert.pem -outform PEM -days 1825

You should be prompted for a passphrase, and see output similar to this:

Generating a 2048 bit RSA private key
.................................+++
.................................................................................................+++
writing new private key to '/home/bshumate/myCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

Do not forget the passphrase used with the command above! You’ll need it every time you want to generate and sign a new server or client certificate!

• ~/myCA/cacert.pem : CA public certificate

• ~/myCA/private/cakey.pem : CA private key

Optional Step

Strip the certificate from all its text to keep only the -CERTIFICATE- section to create a crt

openssl x509 -in cacert.pem -out cacert.crt

Creating a Self-Signed Server Certificate

Now that you have a Certificate Authority configured, you may use it to sign self-signed certificates. Prior to beginning the steps below, you may wish to encrypt the certificate’s private key with a passphrase. The advantages of encrypting the key with a passphrase include protection of the certificate in the event it is stolen.

The certificate cannot be used with SSL-enabled applications without entering the passphrase every time the SSL-enabled application is started. This condition, while being most secure, can present a problem: If the server must be started in an unattended manner as in the case of a computer restart, then no one will be available to enter the passphrase, and subsequently the server will not start. One way to eliminate this condition involves a trade-off in security: The key may be decrypted, to remove the passphrase necessity; thus SSL-enabled applications will start automatically, without a need for you to enter a passphrase.

Create the server configuration file, by editing ~/myCA/exampleserver.cnf with your favorite text editor. Add this example content:

#
# exampleserver.cnf
#

[ req ]
prompt                  = no
distinguished_name      = server_distinguished_name
req_extensions          = v3_req

[ server_distinguished_name ]
commonName              = tradeshowhell.com
stateOrProvinceName     = NC
countryName             = US
emailAddress            = root@tradeshowhell.com
organizationName        = My Organization Name
organizationalUnitName  = Subunit of My Large Organization

[ v3_req ]
basicConstraints        = CA:FALSE
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName          = @alt_names

[ alt_names ]
DNS.0                   = tradeshowhell.com
DNS.1                   = alt.tradeshowhell.com

Be sure to change the values under server_distinguished_name especially the commonName value. The commonName value must match the host name, or CNAME for the host you wish to use the key for. If the commonName does not match the intended hostname, then host / certificate mismatch errors will appear in the client applications of clients attempting to access the server.

The previous command sets an environment variable OPENSSL_CONF which forces the openssl tool to look for a configuration file in an alternative location (in this case, ~/myCA/exampleserver.cnf).

Now generate the certificate, and key:

You should be prompted for a passphrase, and see output similar to this:

Generating a 1024 bit RSA private key
...++++++
...............++++++
writing new private key to 'tempkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

Don’t forget the passphrase!

Enter pass phrase:
writing RSA key

Remember: If you use a server key encrypted with a passphrase, the passphrase will have to be entered each time the server application using the encrypted key is started. This means the server application will not start unless someone, or something enters the key.

Now you need to sign the server certificate with the Certificate Authority (CA) key using these commands:

The previous command modifies the environment variable OPENSSL_CONF which forces the openssl tool to look for a configuration file in an alternative location (in this case, ~/myCA/caconfig.cnf to switch back to the CA configuration).

You will be prompted for the passphrase of the CA key as created in the Certificate Authority setup from above. Enter this passphrase at the prompt, and you will then be prompted to confirm the information in the exampleserver.cnf, and finally asked to confirm signing the certificate. Output should be similar to this:

Using configuration from /home/bshumate/myCA/caconfig.cnf
Enter pass phrase for /home/bshumate/myCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :PRINTABLE:'tradeshowhell.com'
stateOrProvinceName   :PRINTABLE:'NC'
countryName           :PRINTABLE:'US'
emailAddress          :IA5STRING:'root@tradeshowhell.com'
organizationName      :PRINTABLE:'Trade Show Hell'
organizationalUnitName:PRINTABLE:'Black Ops'
Certificate is to be certified until Jan  4 21:50:08 2011 GMT (1825 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Congratulations! You now have a self-signed server application certificate, and key pair:

• server_crt.pem : Server application certificate file

• server_key.pem : Server application key file

Use the documentation provided with the server application you wish to use the certificate, and key for in order to properly use it. See the Configuring Apache for SSL Support section below for an example usage.

Optional Step for Certain Server Applications

cat server_key.pem server_crt.pem > hold.pem
mv      hold.pem server_crt.pem
chmod   400      server_crt.pem

Converting X.509 Certificates to PKCS#12 for Client Applications

You will be prompted for an Export password, which you may use, or just leave blank.

The resultant mycert.pfx file may now be imported into applications such as Web Browsers, and E-Mail clients. Since this certificate represents the Root CA certificate of your server, all subsequent server-level certificates signed by the CA certificate will also be automatically accepted by the client application which installs this PKCS#12 version of the certificate.

Generating Certificate for Signing by Recognized CA

In order to run a production server which will engage in commercial activity, such as «e-commerce», it is required to generate a certificate, and have it signed by a recognized Certificate Authority (CA) such as VeriSign. The process for generating a certificate request, and obtaining a certificate signed by a recognized CA can be difficult. You must complete all requisite «paperwork» prior to creating a certificate request, and ensure all required information is accurate.

You may wish to verify the signature, and information contained in the certificate request. Verify the signature with this command:

and verify the information with this command:

The next steps typically involve pasting the content of the certificate request file into the CA’s signup form, and awaiting the certificate. Also, you should safeguard the key file, as it will be required to use the certificate you receive from the CA.

Using PKCS#12 Certificates in Client Applications

This section of the guide explains using PKCS#12 certificates for SSL connections from the client perspective, and demonstrates the process of importing certificates into the Firefox Web Browser applications, and a couple of the more popular E-Mail clients.

Importation of a root certificate into such applications enables a trusted SSL-encrypted connection to the server from whence the certificate came, free of nagging messages about the certificate being self-signed, and so on.

Importing a Certificate into Mozilla Firefox

Importation of a PKCS#12 certificate into the Mozilla Firefox Web Browser application is very simple:

1. From within Firefox, click Edit > Preferences

2. Click the Advanced icon

3. Click the View Certificates button

4. Click the Import button

5. Browse to the location of the certificate file, which is typically a .pfx file type

6. Highlight the certificate file, and click the Open button

7. You may be prompted to enter Firefox’s Master Password at this point, or to set an initial Master Password. Enter the current, or net password as required, confirm it, and click OK

8. You will then be prompted to enter the certificate’s Export password. If there is no such password attached to the certificate, simply click OK, otherwise enter the password, and click OK

9. A message will appear advising that Firefox has «Successfully restored your security certificate(s) and private key(s)»
11. You have successfully imported the server’s client PKCS#12 certificate into Firefox

Importing a Certificate into Evolution

Importation of a PKCS#12 certificate into the Evolution E-Mail client couldn’t be simpler:

1. From within Evolution, click Edit > Preferences

2. Click the Certificates icon

3. Click the Import button

4. Browse to the location of the certificate file, which is typically a .pfx file type

5. Highlight the certificate file, and click the Open button

6. You may be prompted to enter Evolution’s certificate database password at this point, or to set an initial certificate database password. Enter the current, or new password as required, confirm it, and click OK

7. You will then be prompted to enter the PKCS12 File Password. If there is no such password attached to the certificate, simply click OK, otherwise enter the password, and click OK

8. You should see the certificate, and its details appear in the Your Certificates section of the Evolution Settings window

9. Click the Close button

10. You have successfully imported the server’s client PKCS#12 certificate into Evolution

Importing a Certificate into Mozilla Thunderbird

Importation of a PKCS#12 certificate into the Mozilla Thunderbird E-Mail client application is very simple:

1. From within Thunderbird, click Edit > Preferences

2. Click the Advanced icon

3. Click the Certificates entry in the right pane

4. Click the Manage Certificates button

5. Click the Import button

6. Browse to the location of the certificate file, which is typically a .pfx file type

7. Highlight the certificate file, and click the Open button

8. You may be prompted to enter Thunderbird’s Master Password at this point, or to set an initial Master Password. Enter the current, or new password as required, confirm it, and click OK

9. You will then be prompted to enter the certificate’s Export password. If there is no such password attached to the certificate, simply click OK, otherwise enter the password, and click OK

10. A message will appear advising that Thunderbird has «Successfully restored your security certificate(s) and private key(s)»
12. You have successfully imported the server’s client PKCS#12 certificate into Thunderbird

Importing a Certificate into the System-Wide Certificate Authority Database

You can import a CA Certificate into the system-wide database of trusted certificate authorities. Applications that use this database will automatically trust any certificates stored here.

1. Copy your certificate to the system certificate directory. At a terminal prompt, type:

$ sudo cp mycert.pem /usr/share/ca-certificates/mycert.crt

# This file lists certificates that you wish to use or to ignore to be
# installed in /etc/ssl/certs.
# update-ca-certificates(8) will update /etc/ssl/certs by reading this file.
#
# This is autogenerated by dpkg-reconfigure ca-certificates.
# certificates shoule be installed under /usr/share/ca-certificates
# and files with extension '.crt' is recognized as available certs.
#
# line begins with # is comment.
# line begins with ! is certificate filename to be deselected.
#
mycert.crt
brasil.gov.br/brasil.gov.br.crt
cacert.org/cacert.org.crt
mozilla/ABAecom_=sub.__Am._Bankers_Assn.=_Root_CA.crt
[... many additional certificates omitted ...]

Instead of manually editing this file, you can run

3. Update the CA certificates database by typing:

$ sudo update-ca-certificates

4. You have successfully imported your certificate into the system CA certificates database.

Add certificate files to opensearch. yml

This process generates many files, but these are the ones you need to add to each node:

• root-ca.pem
• admin.pem
• admin-key.pem
• (Optional) node1.pem
• (Optional) node1-key.pem

On one node, the security configuration portion of opensearch.yml might look like this:

Практика CA Smallstep

Установка Smallstep и CLI step 

CA Smallstep — это open source CA, который можно развернуть локально для автоматического получения X.509 сертификатов. На официальном сайте есть ряд инструкций по его установке и настройке.  Для экспериментов я использовал вариант с docker:

• Краткая выжимка из инструкции по установке на RH Linux. Сначала устанавливаем docker:

sudo yum -y update

sudo yum install -y yum-utils

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

sudo yum -y install docker-ce

sudo systemctl start docker

• Проверяем корректность установки docker:

sudo docker run hello-world

sudo docker pull smallstep/step-ca

• Инициализируем наш CA:

docker run -it -v step:/home/step smallstep/step-ca step ca init

должна вернуться строка:

На этом же или другом компьютере по инструкции  устанавливаем утилиту CLI step. Краткая выжимка:

• Загружаем бинарник step: https://github.com/smallstep/cli/releases/tag/v0.19.0

tar -xf step_linux_0.19.0_386.tar.gz

• Копируем утилиту step в /usr/bin

• Регистрируем CLI step для использования с нашим CA. Этот процесс называется «bootstrap».  Значение параметра «ca-url» — это IP и порт, на котором запущен Smallstep CA, «fingerprint » — это сохраненное значение при инициализации CA:

• Проверка связи с CA:

step ca health

должна вернуться строка:

Все готово для генерации ключей и сертификатов.

Генерация ключей и сертификатов 

Также как и в случае с OpenSSL, сначала генерируем ключ и сертификат для сервера и установки TLS соединения, потом для клиента и установки mTLS. 

• В отличии от OpenSSL, CA Smallstep может одновременно сформировать приватный ключ сервера 2048-бит RSA (server.key) и запрос на сертификат (server.csr). В запросе явно указываем, что пароль должен быть пустой (no-password), xx.xx.xx.xx — это IP адрес сервера, для которого генерируется запрос: 

step certificate create --csr --no-password --insecure --kty=RSA --size=2048 "xx.xx.xx.xx" server.csr server.key

• Подписываем сертификат на нашем CA Smallstep:

step ca sign server.csr server.crt

• Смотрим полученный сертификат: 

step certificate inspect server.crt

• Получаем с CA Smallstep его корневой сертификат: 

step ca root root_ca.crt

• Смотрим корневой сертификат:

step certificate inspect root_ca.crt

• Аналогично OpenSSL копируем ключи и сертификаты на наш HTTPS сервер:

• Проверяем сервер curl-ом:

Все нормально, теперь генерируем ключ и сертификат для клиента.

• Аналогично серверу одновременно формируем приватный ключ клиента 2048-бит RSA (client.key) и запрос на сертификат (client.csr). Явно указываем, что пароль должен быть пустой (no-password), xx.xx.xx.xx — это IP адрес клиента, для которого генерируется запрос: 

step certificate create --csr --no-password --insecure --kty=RSA --size=2048 "xx.xx.xx.xx" client.csr client.key

• Подписываем сертификат на CA:

step ca sign client.csr client.crt

step certificate inspect client.crt

• Получаем корневой сертификат CA:

step ca root root_ca.crt

• Смотрим корневой сертификат:

step certificate inspect root_ca.crt

• Копируем на клиента:

• Для проверки вызываем curl с параметрами:

curl --cert ./client.crt --key client.key --cacert root_ca.crt https://xx.xx.xx.xx:9443

Отлично — mTLS тоже работает с выданными CA Smallstep сертификатами!

Дополнительные возможности CA Smallstep

С помощью CLI step можно проверить необходимость обновления сертификата: 

step certificate needs-renewal server.crt

• Если обновление не требуется возвращается строка:

certificate does not need renewal

• Если требуется, то строка пустая и тогда необходимо обновить сертификат:

step ca renew server.crt server.key

• При необходимости сертификат можно отозвать, в этом случае его невозможно будет продлить, только получить заново:

step ca revoke --cert server.crt --key server.key

• Посмотреть все сертификаты в цепочке: 

step certificate inspect server.crt --bundle

• Запуск CLI step в режиме отладки:

STEPDEBUG=1 step /команда/

Certification Authority

If the services on your network require more than a few self-signed certificates it may be worth the additional effort to setup your own internal Certification Authority (CA). Using certificates signed by your own CA, allows the various services using the certificates to easily trust other services using certificates issued from the same CA.

First, create the directories to hold the CA certificate and related files:

sudo mkdir /etc/ssl/CA
sudo mkdir /etc/ssl/newcerts

The CA needs a few additional files to operate, one to keep track of the last serial number used by the CA, each certificate must have a unique serial number, and another file to record which certificates have been issued:

sudo sh -c "echo '01' > /etc/ssl/CA/serial"
sudo touch /etc/ssl/CA/index.txt

dir             = /etc/ssl              # Where everything is kept
database        = $dir/CA/index.txt     # database index file.
certificate     = $dir/certs/cacert.pem # The CA certificate
serial          = $dir/CA/serial        # The current serial number
private_key     = $dir/private/cakey.pem# The private key

Next, create the self-signed root certificate:

openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

You will then be asked to enter the details about the certificate.

Now install the root certificate and key:

sudo mv cakey.pem /etc/ssl/private/
sudo mv cacert.pem /etc/ssl/certs/

sudo openssl ca -in server.csr -config /etc/ssl/openssl.cnf

After entering the password for the CA key, you will be prompted to sign the certificate, and again to commit the new certificate. You should then see a somewhat large amount of output related to the certificate creation.

There should now be a new file, /etc/ssl/newcerts/01.pem, containing the same output. Copy and paste everything beginning with the line: ——BEGIN CERTIFICATE—— and continuing through the line: —-END CERTIFICATE—— lines to a file named after the hostname of the server where the certificate will be installed. For example mail.example.com.crt, is a nice descriptive name.

Subsequent certificates will be named 02.pem, 03.pem, etc.

Replace mail.example.com.crt with your own descriptive name.

Finally, copy the new certificate to the host that needs it, and configure the appropriate applications to use it. The default location to install certificates is /etc/ssl/certs. This enables multiple services to use the same certificate without overly complicated file permissions.

For applications that can be configured to use a CA certificate, you should also copy the /etc/ssl/certs/cacert.pem file to the /etc/ssl/certs/ directory on each server.

Create Certificate Authority

As discussed earlier, we need to create our own root CA certificate for browsers to trust the self-signed certificate. So let’s create the root CA certificate first.

Let’s create a directory named openssl to save all the generated keys & certificates.

mkdir openssl && cd openssl

openssl req -x509 \
            -sha256 -days 356 \
            -nodes \
            -newkey rsa:2048 \
            -subj "/CN=demo.mlopshub.com/C=US/L=San Fransisco" \
            -keyout rootCA.key -out rootCA.crt 

We will use the rootCA.keyand rootCA.crt to sign the SSL certificate.

Can't load /home/vagrant/.rnd into RNG

1. Create the Server Private Key

openssl genrsa -out server.key 2048

2. Create Certificate Signing Request Configuration

We will create a csr.conf file to have all the information to generate the CSR. Replace demo.mlopshub.com with your domain name or IP address.

cat > csr.conf <<EOF
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[ dn ]
C = US
ST = California
L = San Fransisco
O = MLopsHub
OU = MlopsHub Dev
CN = demo.mlopshub.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = demo.mlopshub.com
DNS.2 = www.demo.mlopshub.com
IP.1 = 192.168.1.5
IP.2 = 192.168.1.6

EOF

3. Generate Certificate Signing Request (CSR) Using Server Private Key

openssl req -new -key server.key -out server.csr -config csr.conf

Now our folder should have three files. csr.conf, server.csr and server.key

4. Create a external file

cat > cert.conf <<EOF

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = demo.mlopshub.com

EOF

5. Generate SSL certificate With self signed CA

openssl x509 -req \
    -in server.csr \
    -CA rootCA.crt -CAkey rootCA.key \
    -CAcreateserial -out server.crt \
    -days 365 \
    -sha256 -extfile cert.conf

The above command will generate server.crt that will be used with our server.key to enable SSL in applications.

server {

listen   443;

ssl    on;
ssl_certificate    /etc/ssl/server.crt;
ssl_certificate_key    /etc/ssl/server.key;

server_name your.domain.com;
access_log /var/log/nginx/nginx.vhost.access.log;
error_log /var/log/nginx/nginx.vhost.error.log;
location / {
root   /home/www/public_html/your.domain.com/public/;
index  index.html;
}

}

Заключение

В данной статье мы рассмотрели две возможности генерации ключей и сертификатов для клиента и сервера:

• С помощью OpenSSL.

• Используя CA Smallstep.

И двумя способами установили TLS и mTLS соединения:

• С помощью curl.

• Из браузера, загрузив в него клиентский и корневой сертификаты.

Теперь у нас есть понимание, как организовать свою систему PKI с помощью CA любого производителя, т.к. логика взаимодействия у всех аналогичная. Более того, большинство CA используют под капотом OpenSSL, оборачивая его в свой API.

Conclusion

In this guide, we have learned how to create self-signed SSL certificates using OpenSSL.

For production use cases, if you don’t want to spend money on SSL certificates, you can try out Letsencrypt.

Hope this self-signed SSL guide was helpful with the script to automate the certificate generation. Do let us know if you face any issues.

Also, SSL/TLS is one of the important topics in DevOps. You can check out the how to become a devops engineer blog to know more.

Install Certificate Authority In Your Browser/OS

You need to install the rootCA.crt in your browser or operating system to avoid the security message that shows up in the browser when using self-signed certificates.

Installing self-signed CA certificates differs in Operating systems. For example, in MAC, you can add the certificate by double-clicking it and adding it to the keychain. Check the respective Operating system guide on installing the certificate.