Issue and verify a certificate

You will issue an end-entity certificate for device-001 using browser key and CSR generation. The result is device.crt, device.key and the issuing root's public certificate, ca.pem.

Before you begin

An active root CA with an available signing key and permission to issue. If one does not exist yet, follow Create your first CA.
Its public certificate in ca.pem; this example uses the root created in the previous path.
OpenSSL 3.x and a working directory with restricted access.
A client identifier: here we use device-001.

Keep the key before closing the result

In this flow, the client's key is generated in the browser and must be downloaded when issuance finishes. If you lose it, you must generate a key and issue another certificate. The certificate inventory lets you download the public certificate, but cannot recover this key.

Start the issuance

Open the CA from the previous path, go to Issued Certificates and select Issue New.

Choose the method

Select Generate Key & CSR in Browser to follow this example.

If the key must be generated and kept on the destination system, use Upload Existing CSR, described in the authorities guide.

Identify the certificate

Enter device-001 as the Common Name. Add subject details required by your policy and SANs if the consumer uses them to identify the client.

If you continue with manual registration, the Device ID will be exactly device-001.

Configure key and uses

Choose an algorithm and size allowed by the profile; for example, ECDSA P-256 if permitted. For this client certificate, select Digital Signature and Client Authentication, and issue it as an end-entity certificate.

Request, for example, 30 days of validity, always within the CA's lifetime. Review the issuance profile if the resulting content differs from the request.

Issue and download

Confirm issuance. Save the PEM certificate as device.crt and the private key as device.key in your prepared directory.

Verify the result

Check in Issued Certificates that the certificate appears active. Note its serial number and verify the downloaded material using the checks below.

Inspect content and dates

openssl x509 -in device.crt -noout -subject -issuer -serial -dates
openssl x509 -in device.crt -noout -text

Check CN=device-001, the expected issuer, current validity, Digital Signature and the extended usage TLS Web Client Authentication. It must be an end-entity certificate: it must not declare CA:TRUE or enable Certificate Sign. If Basic Constraints is present, it must indicate CA:FALSE. If you requested SANs, check that the expected identifiers appear in the certificate.

Verify the chain

openssl verify -CAfile ca.pem -purpose sslclient device.crt

The expected result is device.crt: OK. This check uses your explicit root and evaluates the chain, dates and compatibility with the TLS client purpose. Also check for the expected usages and names through the inspection above.

If you use an intermediate CA, the trusted root must be in ca.pem and you must supply the intermediates with -untrusted intermediates.pem. This variant is covered in the trust model.

The command does not query OCSP or CRL. For revocation checks, continue with Certificate validation. See the openssl-verify reference for its options.

Check that the key matches

In Bash, compare the two public-key digests:

(
  set -e -o pipefail
  openssl x509 -in device.crt -pubkey -noout \
    | openssl pkey -pubin -outform DER \
    | openssl dgst -sha256

  openssl pkey -in device.key -pubout -outform DER \
    | openssl dgst -sha256
)

Both commands must finish successfully and show the same SHA-256 digest. If they differ, the private key does not match the selected certificate. Find the correct pair before installing it.

The options used are documented in openssl-x509 and openssl-pkey.

If the result fails

Result	What to review
The CA rejects issuance	Permissions, CA state and key, algorithm and profile.
Different subject or usages	Applied profile and requested values.
Issuer cannot be found	Downloaded CA and required intermediate chain.
Validity fails	Certificate and CA dates, and the computer's clock.
Public-key digests differ	Certificate and key files from the same issuance.

See PKI diagnostics to narrow an issuance failure.

Next step

You have completed the PKI path when the certificate verifies and the key matches. Choose how to use it:

Manage certificates for inspection, status and revocation.
Register a device manually to associate this identity with Lamassu's inventory.
Prepare EST for the device to request its next identities.

Acceptance by a consumer requires configuring its trust, revocation checks and permissions granted to the identity.

Issue and verify a certificate

On this page