Skip to content

X.509 auto-approve

Auto-approve function of X.509 autority lets you allow upcoming CSRs to be signed automatically when its subject matches a rule you store in advance. If no rule matches, the CSR stays pending until you handle it through your normal process.

Typical uses:

  • A device or service is about to submit its CSR; you pre-register the exact subject you expect.
  • You want one enrollment to succeed without a separate approval step, then the rule is closed.

Submitting the CSR works the same as always: PUT /{tenant}/x509/csr (or SCEP, if you use it). The profile in the request still controls validity, extensions, and how the subject is built from the CSR—see X.509 profiles.

What you see as a client

  • Rule matches and signing succeeds: you receive the certificate (PEM or DER, depending on the request).
  • No rule matches (or signing fails for another reason): you receive JSON with "result": "PENDING" and a pbid for the CSR, usually with HTTP 202 Accepted.

Rules: collection x509-aa

Add one document per intended one-time approval. SeaCat reads this collection when a CSR arrives.

You manage documents yourself (for example with MongoDB shell, Compass, or your ops tooling). There is no dedicated “create auto-approve” HTTP API.

Fields you set

Field Purpose
tenant Tenant id (same as in the API path). Required.
subject_CN, subject_O, subject_OU, subject_C, subject_L, … Expected subject, using short names (CN, O, OU, …). Each field is a JSON array of strings, even for a single value. Required for every attribute present in the CSR subject you expect.
state Optional. Use any value except rejected or approved for a rule that should still match (for example omit the field, or use pending).

The CSR’s subject must match the document exactly for those attributes: same types (CN, O, …), same values, and for repeated attributes (e.g. several OU), the same order as in the CSR.

Tip

Use arrays for every subject_* value, e.g. "subject_CN": ["my-device"], not a plain string.

Examples to insert

1. Only a common name

CSR subject will be CN=my-router-01.

{
    "tenant": "my-tenant",
    "subject_CN": ["my-router-01"]
}

2. Several distinguished name components

CSR subject like CN=Sensor 42,O=My Company Ltd,C=CZ.

{
    "tenant": "my-tenant",
    "subject_CN": ["Sensor 42"],
    "subject_O": ["My Company Ltd"],
    "subject_C": ["CZ"]
}

3. Multiple organizational units (order matters)

If the CSR subject lists two OU values in this order, the document must use the same order in subject_OU.

{
    "tenant": "my-tenant",
    "subject_CN": ["api.internal"],
    "subject_OU": ["Platform", "Production"],
    "subject_O": ["My Company Ltd"],
}

4. Using MongoDB shell

Point the shell at the same MongoDB database your SeaCat PKI instance uses for storage, then:

db.getCollection("x509-aa").insertOne({
    tenant: "my-tenant",
    subject_CN: ["new-gateway-07"]
})

What SeaCat updates after a successful signing

When a CSR matches your rule and a certificate is issued, SeaCat updates that x509-aa document so it is not reused:

  • state becomes approved
  • approved_at is set
  • pbid points to the issued certificate

You can use this for audit: which approval row produced which certificate.

The example for DLMS/Cosem

{
    "tenant": "my-tenant",
    "subject_CN": [
        "545354004FFFFFFF"
    ],
    "data": {
        "logical_device_name": "54535478787831323334314130303030",
        "production_date": "2023-08-23",
        "serial_number": "2211040037"
    },
}
  • subject_CN: a 16-character hexadecimal encoding of the DLMS/COSEM system title
  • data: this section is not used by TeskaLabs SeaCat PKI but it can be used for integration/evidence purposes

Practical checklist

  1. Decide the exact subject the CSR will use (inspect a sample CSR or your device template).
  2. Insert a document into x509-aa with matching tenant and subject_* arrays.
  3. Submit the CSR with the right profile (query parameter profile on PUT /{tenant}/x509/csr, or your SCEP profile setting).
  4. If you need another device later, insert a new document; a used rule is marked approved and will not match again.