TuringSign
An order-based commercial CA issuer, with CSR-driven enrollment and asynchronous domain validation.
Overview
TuringSign is registered as an issuer type in Cockpit's PKI module. The connector places a certificate order against the TuringSign platform, then polls the order until the certificate is ready — either immediately (pre-validated products) or after domain-control validation completes on the provider's side.
The connector authenticates with the API ID and API Key, then places and polls orders against the TuringSign platform.
| Property | Value |
|---|---|
| Issuer type | turing-sign |
| Issuance model | Order-based: place an order, then poll for the issued certificate |
| CSR requirement | A PKCS#10 CSR is mandatory on every order (Cockpit generates one automatically if the request does not supply it) |
| Key custody | Caller/CSR-based by default — TuringSign itself never returns a private key. If a request omits a CSR, Cockpit generates the key pair itself and hands back the private key once, the same as internal-CA managed-key issuance |
| Default API endpoint | TuringSign's demo environment, used only when {api_base_url} is left blank |
When left blank, the connector's API base URL defaults to TuringSign's demo environment. For a production deployment, explicitly set {api_base_url} to your TuringSign / reseller production endpoint when registering the issuer.
Configuration
The issuer wizard for TuringSign collects two groups of information: non-secret configuration and encrypted credentials.
Config fields
| Field | Purpose |
|---|---|
api_base_url | Optional. TuringSign API base URL. Leave blank to use the demo environment. |
product_id | Numeric identifier of the SSL product to order, looked up from the account's product catalog. |
signing_ca_type | Signing CA selection: automatic (default), rsa, or ecc. |
subscriber_id | The RA-provisioned subscriber the order is placed under. |
contact_id | The order contact, chosen from the selected subscriber's contacts. |
default_validity_days | Certificate validity applied when a request does not specify one (default 365). |
The issuer wizard populates the product, subscriber and contact dropdowns live from your TuringSign account once the API ID and API Key are entered, so these values are picked rather than typed.
Credentials
| Field | Purpose |
|---|---|
app_id | API ID issued to your account (used to authenticate to TuringSign). |
secret | API Key paired with the API ID. |
The API ID and API Key are exchanged for a short-lived bearer token on every operation; they are encrypted at rest and never echoed back by the platform.
Registering the issuer
Enter the API ID and API Key
Provide the TuringSign API ID and API Key. The wizard uses them to authenticate and populate the product, subscriber and contact dropdowns.
Choose the product, subscriber and contact
Select the SSL product to order against, the subscriber the order is filed under, and the order contact.
Set the signing CA type and default validity
Choose automatic, rsa or ecc for CA selection, and a default certificate validity.
Test the connection
Run test-connection to confirm the API ID/Key authenticate and the product catalog is reachable.
Issue through the issuer
Request certificates against the issuer. Cockpit supplies (or generates) the CSR, dns names and validity on each order.
Submitting a CSR is optional. If a request omits one, Cockpit generates the key pair and CSR on your behalf (TuringSign's order endpoint requires a CSR on every order) and returns the private key once, alongside the issued certificate — capture and store it at issuance time, since it is not retrievable afterwards. If you supply your own CSR, you keep the private key and TuringSign never sees it.
Issuance flow
TuringSign is the one issuer connector in this catalog that is genuinely asynchronous: placing an order does not always return a certificate right away, so the connector polls before deciding whether to return a result immediately or hand back a pending order.
A short synchronous poll covers pre-validated products; anything still awaiting domain-control validation comes back as pending and is completed later against the same order reference.
Supported operations
| Operation | Supported | Notes |
|---|---|---|
| test-connection | Yes | Authenticates and confirms the product catalog is reachable. |
| issue | Yes | Places an order, then polls briefly for immediate issuance; see below for the asynchronous path. |
| renew | Yes | No native renewal flow — renew places a fresh order with the same request. |
| revoke | Yes | Revokes the order's certificate using the order reference captured at issue time, with an optional reason and comment. |
Asynchronous domain validation
Some products (typically domain-validated certificates) are not issued instantly — TuringSign must complete domain-control validation first. When an order is not ready within a short synchronous window after being placed, Cockpit does not fail the request: it records the certificate as pending, keyed by the TuringSign order reference, and completes it once TuringSign finishes validation.
Complete outstanding domain-control validation in the TuringSign portal for pending orders. Once validation succeeds, Cockpit's refresh/poll behavior picks up the issued certificate against the same order reference — no need to re-submit the request.
The TuringSign connector is built against the provider's published API contract. It has not yet been exercised against a live TuringSign tenant in production. Before relying on it for production issuance, verify that your subscriber, contact and product records are correctly provisioned in the TuringSign portal, and validate a full issue/revoke cycle in a non-production issuer first.