Openssl ca

From UVOO Tech Wiki
Jump to navigation Jump to search

Simple init-ca.sh script

.env.secret

export ROOTCA_PASS=ChangeThis
export SUBCA_PASS=ChangeThat

source env vars

. .env.secret

init-ca.sh

#!/bin/bash
set -eu

if test -f initialized; then
  exit 0
fi

# Generate Root CA key
openssl genpkey -aes256 -algorithm RSA -out rootCA.key -pass env:ROOTCA_PASS

openssl req -x509 -new -key rootCA.key -out rootCA.crt -days 365 -subj "/CN=Root CA" -passin env:ROOTCA_PASS -addext "basicConstraints=CA:true,pathlen:1"

# Generate Sub-CA certificate signing request
openssl genpkey -aes256 -algorithm RSA -out subCA.key -pass env:SUBCA_PASS
openssl req -new -key subCA.key -out subCA.csr -subj "/CN=Sub CA" -passin env:SUBCA_PASS -addext "basicConstraints=CA:true,pathlen:0"

# Sign the Sub-CA certificate using the Root CA
openssl x509 -req -in subCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out subCA.crt -days 365 -passin env:ROOTCA_PASS -copy_extensions copyall


cat subCA.crt rootCA.crt > ca.crt

# Generate Client key
openssl genpkey -aes256 -algorithm RSA -out client.key -pass env:SUBCA_PASS

# Generate Client certificate signing request
openssl req -new -key client.key -out client.csr -subj "/CN=Client" -passin env:SUBCA_PASS -addext "subjectAltName = URI:https://www.example.org/resource" -addext "extendedKeyUsage = clientAuth"
openssl req -text -in client.csr

# Sign CA and allow all extentions from CSR
openssl x509 -req -in client.csr -CA subCA.crt -CAkey subCA.key -passin env:SUBCA_PASS -out client.crt -days 365 -copy_extensions copyall
openssl x509 -text -in client.crt

# Create and sign foo.example.com
openssl genpkey -algorithm RSA -out foo.key  # to encrypt add -aes256
openssl req -new -key foo.key -out foo.csr -subj "/CN=foo.example.com" -addext "subjectAltName=DNS:foo.example.com,DNS:foo1.example.com,DNS:foo2.example.com,DNS:foo3.example.com,DNS:foo4.example.com,DNS:foo5.example.com,IP:192.168.1.1"
openssl x509 -req -in foo.csr -CA subCA.crt -CAkey subCA.key -passin env:SUBCA_PASS -out vault.crt -days 365 -copy_extensions copyall

date > initialized

Automation

Only include intermediateCA(s) in ssl_trusted_certificate & SSLCertificateChainFile NOT rootCA

NGINX

ssl_certificate /path/to/server_cert.pem;
ssl_certificate_key /path/to/server_key.pem;
ssl_trusted_certificate /path/to/intermediate1.pem /path/to/intermediate2.pem;

Apache

    SSLEngine on
    SSLCertificateFile /path/to/server_cert.pem
    SSLCertificateKeyFile /path/to/server_key.pem
    SSLCertificateChainFile /path/to/intermediate_cert.pem

Notes

Subject Alternative Name Types

In X.509 certificates, the Subject Alternative Name (SAN) extension allows for including additional identifiers or endpoints associated with the subject of the certificate. The SAN extension can accommodate various types of identifiers, each represented by a different type of SAN entry. The following are some of the most commonly used SAN types:

DNS Name (dNSName): Specifies a DNS domain name. This is commonly used for web server certificates to secure domain names.
IP Address (iPAddress): Specifies an IP address, either IPv4 or IPv6. This is useful for certificates used in network communications.
Email Address (rfc822Name or email): Specifies an email address. This is often used for certificates associated with email servers or client authentication.
Uniform Resource Identifier (URI): Specifies a URI, which can represent various types of resources, including web addresses, file paths, LDAP entries, etc. URIs are represented using the "UniformResourceIdentifier" type.
Directory Name (directoryName): Specifies a Distinguished Name (DN) of another entity. This is useful when the subject of the certificate is an entity other than the issuer, and it needs to refer to another entity by its DN.
Other Name (otherName): Specifies a custom identifier or a non-standard identifier. This allows for flexibility in defining additional types of identifiers.

Where to put Remote Company info in DN

Common Name (CN):
You can include the remote company's name in the Common Name field (CN) of the CSR. The CN field typically represents the name of the entity the certificate is issued to. For example:
makefile
Copy code
Subject: CN=Remote Company Name
Organization (O) and Organizational Unit (OU):
You can include the remote company's organization name and organizational unit (if applicable) in the Organization (O) and Organizational Unit (OU) fields of the CSR, respectively. For example:
makefile
Copy code
Subject: O=Remote Company, OU=Engineering
Country (C), State (ST), Locality (L), etc. (Optional):
You can include additional location information about the remote company in the Country (C), State (ST), Locality (L), and other fields if desired. For example:
makefile
Copy code
Subject: C=US, ST=California, L=San Francisco

Remote DN (Not Supported)

The Directory Name entry in the Subject Alternative Name (SAN) extension of a certificate typically refers to a remote Distinguished Name (DN), not a local one.

In the context of a client certificate, the Directory Name entry can be used to specify the DN of another entity with which the client certificate is associated or authenticated against. This allows the client certificate to refer to and establish trust relationships with remote entities identified by their DNs.

For example, if a client certificate needs to authenticate with a server or service that requires a specific DN for access control or authorization purposes, the Directory Name entry in the SAN extension can be used to specify the DN of that server or service.

In summary, the Directory Name entry in the SAN extension is typically used to specify remote DNs of entities with which the certificate subject interacts or authenticates.

Private create CSR, CSR is signed by CA

`` Here's the general process:

CSR Generation: You create a Certificate Signing Request (CSR) that includes the public key and information about the entity (e.g., common name, organization) for which the certificate is being requested. This CSR is created with the entity's private key but is not signed by the private key. Signing by CA: You submit the CSR to a Certificate Authority (CA) for signing. The CA verifies the information in the CSR and decides whether to issue a certificate based on that information. Certificate Issuance: If the CA approves the CSR, it signs the CSR with its own private key to create a certificate. This certificate includes the public key and information from the CSR, along with a digital signature created by the CA's private key. Certificate Installation: The signed certificate is then provided back to the entity requesting it. The entity can then use the certificate along with the private key to establish secure connections or authenticate itself. ``

Parts

(mTLS) authentication:

Subject Information:
Common Name (CN): The name of the client entity, often the username or service name.
Organization (O): The organization to which the client belongs.
Organizational Unit (OU): The specific unit or department within the organization.
Country (C): The country where the client is located.
State/Province (ST): The state or province where the client is located.
Locality (L): The city or locality where the client is located.
Email Address: The email address associated with the client.
Issuer Information:
The details of the Certificate Authority (CA) that issued the client certificate.
Validity Period:
Valid From: The date and time from which the certificate is valid.
Valid To: The date and time until which the certificate is valid.
Public Key Information:
Public Key Algorithm: The algorithm used for the public key, such as RSA or ECDSA.
Public Key: The actual public key.
Extended Key Usage:
Any extended key usage purposes for which the client certificate is intended, such as client authentication.
Subject Alternative Names (SAN) (if applicable):
Additional names (e.g., DNS names, IP addresses) to which the certificate applies.
Signature Algorithm:
The algorithm used to sign the certificate.

v3

Client certificates used in Mutual TLS (mTLS) authentication may include various X.509v3 extensions to convey additional information or define specific usage purposes. Here are some common X.509v3 extensions found in client certificates for mTLS:

Key Usage (keyUsage):
Specifies the purposes for which the public key in the certificate can be used, such as digital signature, key encipherment, or client authentication.
Extended Key Usage (extendedKeyUsage):
Specifies the purposes for which the certificate can be used beyond the basic key usage, such as client authentication, server authentication, or code signing.
Subject Alternative Name (subjectAltName):
Specifies additional names (e.g., DNS names, IP addresses, email addresses) to which the certificate applies. This extension is often used for multi-domain support.
Issuer Alternative Name (issuerAltName):
Specifies additional names (e.g., DNS names, IP addresses, email addresses) to identify the issuer of the certificate.
Certificate Policies (certificatePolicies):
Specifies the policies and practices with which the certificate complies.
Authority Key Identifier (authorityKeyIdentifier):
Provides a reference to the issuer's public key.
Subject Key Identifier (subjectKeyIdentifier):
Provides a unique identifier for the public key contained in the certificate.
Basic Constraints (basicConstraints):
Specifies whether the certificate is a CA certificate and, if so, the maximum depth of the certification path that may be built using this certificate.
CRL Distribution Points (crlDistributionPoints):
Specifies the locations where the Certificate Revocation List (CRL) associated with the certificate issuer can be found.
Authority Information Access (authorityInfoAccess):
Specifies the locations where additional information about the issuer (such as the CA's certificate) can be retrieved.
These are just some examples of X.509v3 extensions commonly found in client certificates for mTLS. The inclusion of specific extensions may vary depending on the requirements of the certificate issuer and the intended usage of the certificate.

Trash

#!/bin/bash
set -eux
export ROOT_CA_PASS=foo1
export SUB_CA_PASS=foo2


# Generate Root CA key
openssl genpkey -aes256 -algorithm RSA -out rootCA.key -pass pass:$ROOT_CA_PASS

# Generate Root CA certificate
openssl req -x509 -new -key rootCA.key -out rootCA.crt -days 365 -subj "/CN=Root CA" -passin pass:$ROOT_CA_PASS


# Generate Sub-CA key
openssl genpkey -aes256 -algorithm RSA -out subCA.key -pass pass:$SUB_CA_PASS

# Generate Sub-CA certificate signing request
openssl req -new -key subCA.key -out subCA.csr -subj "/CN=Sub CA" -passin pass:$SUB_CA_PASS

# Sign the Sub-CA certificate using the Root CA
openssl x509 -req -in subCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out subCA.crt -days 365 -passin pass:$ROOT_CA_PASS


# Generate Client key
openssl genpkey -aes256 -algorithm RSA -out client.key -pass pass:$SUB_CA_PASS

# Generate Client certificate signing request
openssl req -new -key client.key -out client.csr -subj "/CN=Client" -passin pass:$SUB_CA_PASS -addext "subjectAltName = DNS:client.local" -addext "extendedKeyUsage = clientAuth"
openssl req -text -in client.csr

openssl x509 -req -in client.csr -CA subCA.crt -CAkey subCA.key -passin pass:foo2 -out client.crt -days 365 -copy_extensions copyall
openssl x509 -text -in client.crt


cat << EOF > csr_signing_config.cnf
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = allowed_attrs

[ allowed_attrs ]
basicConstraints = critical,CA:FALSE
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = clientAuth,serverAuth
EOF
openssl x509 -req -in client.csr -CA subCA.crt -CAkey subCA.key -passin pass:foo2 -out client.crt -days 365 -extfile csr_signing_config.cnf -extensions allowed_attrs
openssl x509 -text -in client.crt

echo done

Notes

keyUsage and extendedKeyUsage are both extensions used in X.509 certificates to specify the purposes for which the public key contained in the certificate can be used. However, they serve slightly different purposes:

keyUsage: This extension defines the cryptographic operations for which the public key in the certificate can be used. It specifies the permitted key usages, such as digital signature, key encipherment, data encipherment, key agreement, and certificate signing.
extendedKeyUsage: This extension further refines the usage of the certificate beyond what is covered by keyUsage. It specifies the specific extended key usages, such as client authentication, server authentication, code signing, email protection, and time stamping.
In summary, keyUsage is more general and covers basic cryptographic operations, while extendedKeyUsage provides more specific details about how the certificate can be used, including specific application purposes. Both extensions are optional in a certificate, and their presence or absence can impact how the certificate is interpreted and used by various systems.

Passwords

env:somevar to get the password from an environment variable
file:somepathname to get the password from the first line of the file at location pathname
fd:number to get the password from the file descriptor number.
stdin to read from standard input
Now that I've written this question and answer, it all seems obvious. But it certainly took some time to figure out and I'd seen it take others similar time, so hopefully this can cut down that time and answer faster for others! :)

With OpenSSL 1.0.1e the parameter to use is -passin or -passout. So this example would be:

openssl aes-256-cbc -in some_file.enc -out some_file.unenc -d -passin pass:somepassword
Retrieved from "https://tech.uvoo.io/index.php?title=Openssl_ca&oldid=5261"