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 apbidfor 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:
statebecomesapprovedapproved_atis setpbidpoints 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 titledata: this section is not used by TeskaLabs SeaCat PKI but it can be used for integration/evidence purposes
Practical checklist¶
- Decide the exact subject the CSR will use (inspect a sample CSR or your device template).
- Insert a document into
x509-aawith matchingtenantandsubject_*arrays. - Submit the CSR with the right profile (query parameter
profileonPUT /{tenant}/x509/csr, or your SCEP profile setting). - If you need another device later, insert a new document; a used rule is marked
approvedand will not match again.