Authentication
8 minute read
DigiCert® ONE API integrations rely on service users. Service users are non-interactive identities created specifically for making API calls.
You can authenticate a service user using two primary methods:
| Method | Best for | How it works |
|---|---|---|
| API token (default) | CI/CD pipelines, backend services | Add the service user API token in the x-api-key request header. |
| Mutual TLS (mTLS) | High-assurance, network-restricted, or key-rotation-averse environments | Present a client TLS certificate and prepend clientauth. to the hostname. See Set up service user multi-factor authentication |
What is a service user?
A service user is a non-interactive identity created specifically for API integrations in DigiCert® ONE. It acts as a credential container for one or more authentication credentials, such as API tokens or client authentication certificates.
Service users:
- Authenticate using API tokens or client certificates.
- Cannot sign in to the user interface.
- Are created in Account Manager (through browser or API).
- Can hold multiple credentials, which supports safer credential rotation.
Best practices for service users and API tokens
A service user is the long-lived identity for an integration. API tokens are credentials issued to that service user. Because a single service user can hold multiple tokens, you can rotate credentials without recreating the integration identity or interrupting traffic.
Follow these best practices when creating and managing service users for API access:
- Create one service user per integration or workload. Do not share the same service user across unrelated applications, teams, or environments. Separate service users make it easier to apply least privilege, track ownership, and rotate credentials safely.
- Separate environments. Use different service users for development, staging, and production. This reduces the risk of using the wrong credential in the wrong environment and limits the impact of credential exposure.
- Assign only the access required. Grant access only to the accounts, managers, and roles the integration needs. Review permissions regularly and remove access that is no longer required.
- Use clear names and ownership details. Choose a friendly name and description that identify the application, environment, and owning team. Add the email address of the person or team responsible for managing the service user so ownership is clear during maintenance or incident response.
- Set token expiration dates when possible. Not all tokens expire automatically. When supported, configure tokens with an expiration date to reduce long-term credential risk. Even when a token does not have a fixed expiration date, rotate it on a regular schedule.
- Rotate tokens with overlap. Avoid replacing a token during a live cutover with no fallback. Instead, create a new token for the same service user, update the integration to use the new token, verify that requests succeed, and only then disable and delete the old token. This approach helps avoid downtime.
- Store tokens as secrets. Treat tokens like passwords. Store them in a secure secret management system, not in source code, shared documents, chat messages, or CI/CD logs.
- Track token lifecycle details. Maintain an inventory of each token’s purpose, owner, creation date, expiration date, and rotation schedule. Tracking this information helps prevent outages caused by expired or forgotten credentials.
- Disable and delete unused tokens promptly. Remove tokens that are no longer needed, especially after a rotation is complete or an integration is retired.
Create a service user (UI)
- Sign in to .
- In the Manager menu (grid at top right), select Account.
- In the Account menu, select Access > Service users.
- Select Create service user.
- Enter service user details:
- Friendly name Enter a unique display name. The name must include only letters, numbers, spaces, dashes, and underscores. Actions are logged under this name.
- Optional: Description Add additional information about the service user. This description only appears in the Service user details.
- Optional: End date Specify an expiration date (UTC). For example, selecting January 12, 2026 means the service user expires at 23:59:59 UTC.
- Email Provide the email address of the person managing this service user’s credentials. DigiCert ONE does not send emails to this address, so communicate any necessary details directly.
- Accounts that can use this service user Select the accounts that can use this service user for their API integrations.
- DigiCert ONE Manager access Assign one or more DigiCert ONE Managers. The service user can access the API for each assigned manager
- Assign accounts and access:
- In the Accounts that can use this service user field, select the accounts this service user needs to interact with.
- In the DigiCert ONE Manager access field, assign one or more managers the service user will access via the API.
- Select Next.
- On the Roles and permissions page, select the user roles for each manager assigned to the service user.
- Select Create service user.
- In the Service user token ID window, copy the ID and save it securely.
- After saving the token ID, select Close.
API token authentication
Use an API token for straightforward, stateless authentication.
Make API requests:
curl -X GET \
-H "x-api-key: <SERVICE_USER_KEY>" \
https://one.digicert.com/account/api/v1/user
Rotate and scope keys:
- Treat keys like passwords. Store securely and rotate as needed.
- Assign only roles necessary for each service user (least privilege).
Certificate authentication (mTLS)
mTLS replaces API tokens with a secure X.509 digital client certificate for verifying your identity as a service user during API requests.
Create a client authentication certificate (UI)
- Sign in to .
- In the Manager menu (grid at top right), select Account.
- In the Account menu, select Access > Service users.
- In the Friendly name column, select the service user’s friendly name.
- Navigate to the Client authentication certificates section.
- Select Create client authentication certificate.
- Provide the following information:
- Nickname This is the friendly name shown on the Service user details page. The name must be unique and may only include letters, numbers, spaces, dashes, and underscores.
- End date Enter an expiry date for the certificate.
- Encryption Select an encryption algorithm to use for securing communications. DigiCert recommends AES (Advanced Encryption Standard), which is the default selection.
- Signature hash algorithm Select a hash function to use for verifying data integrity.
- Select Generate certificate.
- Copy the certificate’s password and store it in a secure location.
- Select Download certificate and save the certificate.
- Select Close.
API requests with mTLS
With curl, your request looks like:
curl --cert /path/auth-cert.pem --key /path/to/auth-key.pem \
https://clientauth.one.digicert.com/account/api/v1/user
Use the clientauth. hostname and omit the x-api-key header.
API troubleshooting basics
| Symptom | Likely cause | Quick fix |
|---|---|---|
| 401 Unauthorized | Missing/invalid x-api-key or expired certificate | Verify the x-api-key header; confirm the service user is active. |
| 403 Forbidden | Authenticated but lacks required role | Add the needed role in Account Manager or use a different key. |
| 429 Too Many Requests | Burst traffic | Implement backoff; spread calls across service users. |
| 503 Service Unavailable | Maintenance window | Retry after header; escalate if >10 min. |
| SSL handshake failure when using mTLS | Wrong certificate, key mismatch, or incorrect URL | Check cert/key pair and ensure URL prefix is correct. |
| Everything stopped at midnight | Key or service user reached end date | Create/rotate the key before expiry; update all integrations. |
| Works in demo, fails in prod | Using demo key against prod hostname | Generate a new key in production; update DC_BASE environment variable. |
What’s next?
- Make your first API call Walk through prerequisites, environment setup, and pagination.
- Error handling & rate limits Decode
401/403responses and implement retry strategies.