Certificate Generation and Verification

Generate TLS certificates signed by your local CA (or self-signed), inspect certificate details from files and remote hosts, verify trust chains and expiry, and convert between PEM and DER. These are the day-to-day operations of the Elide PKI.

---

Generating certificates

Generate a TLS certificate signed by the Elide local CA:

bash
 elide crt generate example.com www.example.com

This produces example.com.crt and example.com.key in the current directory, signed by the CA stored in the PKI directory (typically ~/.local/share/elide/pki/ca/). If no CA exists, a self-signed certificate is generated automatically as a fallback.

Multiple domains and IPs

Pass any combination of domain names and IP addresses as positional arguments. The first argument becomes the Common Name (CN); all arguments are added as Subject Alternative Names (SANs):

bash
 elide crt generate myapp.local localhost 127.0.0.1 ::1

IP addresses are automatically detected (by attempting to parse them as IpAddr) and added as IP SANs rather than DNS SANs. Wildcard domains like .example.com are supported -- the output filename replaces with _wildcard.

Self-signed certificates

Force a self-signed certificate even when a local CA is available:

bash
 elide crt generate example.com --self-signed

Self-signed certificates are useful for testing or environments where installing a CA is not practical. Browsers and TLS clients will show trust warnings unless the certificate is explicitly trusted.

Client certificates for mTLS

Generate a client certificate for mutual TLS authentication:

bash
 elide crt generate service-name --client

Client certificates have their Extended Key Usage set to ClientAuth instead of ServerAuth. The server must be configured to request and validate client certificates against the same CA.

Custom CA

Sign with a specific CA instead of the default Elide PKI store. Both --ca-cert and --ca-key must be provided together:

bash
 elide crt generate example.com \
 --ca-cert /path/to/ca.crt \
 --ca-key /path/to/ca.key

Bundling the CA chain

Include the CA certificate in the output to produce a full-chain certificate file:

bash
 elide crt generate example.com --bundle

The output example.com.crt will contain the leaf certificate followed by the CA certificate. This is useful for servers that need the complete chain in a single file.

Custom validity period

bash
 elide crt generate example.com --days 90

The default is 365 days.

Output paths

Control where the certificate and key files are written:

bash
# Explicit file paths
 elide crt generate example.com \
 --out-cert ./certs/server.crt \
 --out-key ./certs/server.key

# Output directory (files named after the first domain)
 elide crt generate example.com --out-dir ./certs

When using --out-dir, the files are named {domain}.crt and {domain}.key based on the first positional argument.

Certificate Transparency

If the CA was created with a CT log (via elide crt ca --ct-log), certificates signed by that CA will include an embedded Signed Certificate Timestamp (SCT) in the X.509 SCT extension (OID 1.3.6.1.4.1.11129.2.4.2).

---

CLI reference: generate

elide crt generate [OPTIONS] <DOMAINS...>
FlagDefaultDescription
DOMAINSrequiredOne or more domain names and/or IP addresses. The first becomes the CN; all become SANs
—ca-cert Elide local CACA certificate file to sign with (requires —ca-key)
—ca-key Elide local CACA private key file to sign with (requires —ca-cert)
—self-signedfalseForce a self-signed certificate (skip CA signing)
—days 365Validity period in days
—clientfalseGenerate a client certificate (EKU: ClientAuth) for mTLS
—out-cert ./{domain}.crtOutput certificate file path
—out-key ./{domain}.keyOutput private key file path
—out-dir .Output directory (files named after the first domain)
—bundlefalseInclude the CA certificate in the output (full chain)
—ct-log noneEnable CT log for SCT embedding (provide data directory path)
—jsonfalseOutput in JSON format
CA-signed certificates use the ECDSA P-256 key algorithm by default. The leaf key algorithm is not currently configurable via a CLI flag — it inherits the default from the PKI library.

---

Inspecting certificates

Display the details of a certificate from a local file or a remote TLS connection.

Inspect a local file

bash
 elide crt inspect ./cert.pem

Output includes subject, issuer, serial number, validity dates, SHA-256 fingerprint, SANs (DNS and IP), CA status, key algorithm, key usage, extended key usage, embedded SCTs, and days remaining.

Inspect a remote host

bash
 elide crt inspect example.com

This connects to example.com:443, performs a TLS handshake, and extracts the peer certificate. To use a custom port:

bash
 elide crt inspect example.com:8443

A target is treated as a remote host when it does not contain / or \, and does not end with .pem, .crt, .der, or .cer.

Full certificate chain

Show all certificates in the chain (leaf, intermediates, root):

bash
 elide crt inspect example.com --chain

Each certificate is printed with a separator and index number.

Brief output

A compact one-line format suitable for dashboards and quick checks:

bash
 elide crt inspect example.com --brief

Output format: {subject} issuer={issuer} expires={not_after} remaining={days}d

If embedded SCTs are present, the count is appended: scts=1.

DER input

If the input file is DER-encoded rather than PEM:

bash
 elide crt inspect ./cert.der --der

---

CLI reference: inspect

elide crt inspect [OPTIONS] <TARGET>
FlagDefaultDescription
TARGETrequiredFile path, remote host (host[:port]), or - for stdin
—chainfalseShow all certificates in the chain
—derfalseTreat the input as DER-encoded (not PEM)
—brieffalseCompact one-line output
—jsonfalseOutput in JSON format
---

Verifying certificates

Validate a certificate's expiry, hostname, CA chain, and optionally its OCSP revocation status. The exit code reflects the result: 0 for valid, 1 for invalid.

Verify a local certificate

bash
 elide crt verify ./cert.pem

This checks whether the certificate has expired and, if --expiry-warn is set (default: 30 days), whether it is close to expiring.

Verify against a CA

bash
 elide crt verify ./leaf.crt --ca ./ca.crt

Chain verification checks that the certificate's issuer matches the CA's subject and that the CA has the CA:true basic constraint.

Verify a remote host

bash
 elide crt verify example.com

When verifying a remote host, the hostname is automatically checked against the certificate's SANs. The chain is considered valid if the remote server presents multiple certificates (leaf + intermediates).

Hostname verification

Explicitly verify a hostname against the certificate's SANs, including wildcard matching (*.example.com matches sub.example.com):

bash
 elide crt verify ./cert.pem --hostname api.example.com

OCSP revocation check

Check the certificate's revocation status via OCSP:

bash
 elide crt verify ./cert.pem --ocsp

OCSP checks are non-fatal: if the OCSP responder is unreachable or the certificate lacks an AIA extension, the check produces a warning but does not fail the overall verification. A Revoked status, however, causes the verification to report INVALID.

Expiry warning threshold

Produce a warning when the certificate expires within a given number of days. The certificate is still reported as valid, but the warning appears in the output:

bash
 elide crt verify ./cert.pem --expiry-warn 60

The default threshold is 30 days.

CI integration

Use the exit code and JSON output for automated certificate monitoring:

bash
if ! elide crt verify production.example.com --expiry-warn 14 --json > /dev/null 2>&1; then
 echo "Certificate validation failed"
  exit 1
fi

---

CLI reference: verify

elide crt verify [OPTIONS] <CERT>
FlagDefaultDescription
CERTrequiredCertificate file path or remote host (host[:port])
—ca noneCA certificate file to verify the chain against
—ocspfalseCheck OCSP revocation status
—expiry-warn 30Warn if certificate expires within N days
—hostname noneHostname to verify against certificate SANs
—jsonfalseOutput in JSON format
---

Exporting and converting

Convert certificates between PEM and DER formats, or bundle multiple certificates into a chain file.

PEM to DER

bash
 elide crt export cert.pem --out cert.der

The output format is inferred from the file extension (.der produces DER; .pem, .crt, .cer produce PEM). Override with --format:

bash
 elide crt export cert.pem --format der --out cert.bin

DER to PEM

bash
 elide crt export cert.der --out cert.pem

Bundle a certificate chain

Combine a leaf certificate with its CA into a single PEM chain file:

bash
 elide crt export leaf.crt --chain ca.crt --out fullchain.pem

The output contains the certificates in order: the input file first, then the chain file contents. DER inputs are automatically converted to PEM for bundling.

---

CLI reference: export

elide crt export [OPTIONS] <INPUT> --out <OUTPUT>
FlagDefaultDescription
INPUTrequiredInput certificate file (PEM or DER, auto-detected)
—out requiredOutput file path
—format from extensionOutput format: pem or der
—chain noneCA/intermediate chain file to bundle with the certificate
—key nonePrivate key file (reserved for future PKCS12 support)
—password nonePassword for PKCS12 output (reserved for future use)
—jsonfalseOutput in JSON format
PKCS12 output (.p12/.pfx) is planned but not yet implemented. The —key and —password flags are accepted by the CLI parser for forward compatibility.

---

End-to-end examples

Local development HTTPS with full chain

bash
# Create a CA and trust it
 elide crt ca
 sudo elide crt trust

# Generate a certificate with the CA chain bundled
 elide crt generate myapp.local localhost 127.0.0.1 \
 --bundle --out-dir ./certs

# Verify it
 elide crt verify ./certs/myapp.local.crt \
 --ca ~/.local/share/elide/pki/ca/ca.crt \
 --hostname myapp.local

mTLS between two services

bash
# Create a shared CA
 elide crt ca --name "Internal Services CA"

# Generate server certificate
 elide crt generate api.internal --out-dir ./server-certs

# Generate client certificate
 elide crt generate client-service --client --out-dir ./client-certs

# Verify the client cert was signed by the same CA
 elide crt verify ./client-certs/client-service.crt \
 --ca ~/.local/share/elide/pki/ca/ca.crt

Monitor production certificate expiry

bash
# Check multiple hosts, fail if any expires within 14 days
for host in api.example.com app.example.com cdn.example.com; do
 echo "--- $host ---"
 elide crt verify "$host" --expiry-warn 14
done

Inspect and compare certificates

bash
# Extract subjects from the full chain of a production host
 elide crt inspect api.example.com --chain --json | jq '.[].subject'

# Quick summary of all certs in the chain
 elide crt inspect api.example.com --chain --brief

ACME renewal with Cloudflare DNS

bash
# Obtain a certificate for a wildcard domain
 elide crt renew "*.example.com" example.com \
 --acme-email admin@example.com \
 --dns cloudflare \
 --dns-token "$CF_API_TOKEN" \
 --out-dir ./certs

# Force renewal even if the current cert is still valid
 elide crt renew example.com \
 --acme-email admin@example.com \
 --dns cloudflare \
 --dns-token "$CF_API_TOKEN" \
 --force

---

See also