Lamassu IoT DocsPKI troubleshooting
Diagnose certificate issuance, OCSP and CRL.
This guide helps a PKI operator locate issuance and status publication failures. Keep the Lamassu version, operation, CA, issuer, serial, time and returned error. Do not include private keys or tokens in diagnostics.
For Gateway, sign-in, pods, dependencies and messaging, see Deployment troubleshooting. For device enrollment, see EST diagnostics.
Issuance fails
| Check | What to inspect | Next step |
|---|---|---|
| CA | Exists, is active and has usable dates. | Authorities. |
| Key | The record has a usable private key and the engine can sign. | Try Sign / Verify in KMS; check provider permissions and availability. |
| CSR | Correct PEM and verifiable signature. | openssl req -in request.csr -noout -verify -text. |
| Profile | Selected source, existing ID, allowed algorithm and size. | Check Profiles precedence; CA and DMS resolve differently. |
| Result | Appropriate subject, SAN, usages and dates. | Compare CSR, profile and certificate; successful issuance does not establish consumer acceptance. |
For unexpected certificate fields, review Honor Subject, Honor Key Usage, Honor Extended Key Usages and Honor Extensions. The latter preserves SAN only, without validating entitlement to those names. Validity is not automatically clamped to CA expiration.
For CA reissuance failures, check revocation and date: reissuance is not supported for a revoked or already expired CA. To change its key, use Hierarchy and rotation.
OCSP or CRL do not reflect a change
Check each boundary independently:
- Record: read the correct certificate again by serial and issuer. Confirm status, reason and time; expired or permanently revoked records reject further transitions.
- Endpoint: inspect AIA and CDP. Query those URLs from the consumer’s network; an old route or incorrect issuer can explain a discrepancy.
- OCSP: save a fresh response, verify signature and timestamps, and observe status. An HTTP error for an absent serial does not mean
Goodor guarantee a signedUnknown. - CRL: compare
latest_crl, number and timestamps with the downloaded list. Check the serial in its contents. If unchanged, reviewregenerate_on_revoke, event delivery, jobs, signing and storage with the deployment operator. - Client: check cache, policy for expired or unavailable evidence, critical IDP extension and rejection of a new connection.
Reactivation from CertificateHold needs a new CRL for the client to stop seeing the hold. Reactivating a CA does not restore its descendant cascade; inspect every status and individual operation failure.
The chain validates but the connection fails
Check expected identity, SAN, KU/EKU, matching key, presented intermediates and consumer permissions. Distinguish server TLS trust, client authentication and action authorization. Follow Validation for positive and rejection tests.
When escalating a problem, provide identifiers, error and relevant public evidence, including query timestamps and version. This distinguishes issuance, publication and consumer application failures.