Internal PKI And Private ACME

SSLNexus can operate as a governed private certificate authority for internal services and devices when the effective Internal PKI entitlement is enabled. The default Enterprise profile includes it. Standard ACME clients keep their private keys locally, while SSLNexus controls who can enroll, which DNS names are allowed, certificate key policy, validity, revocation and audit.

Licence Authority 0.16

R14 reads Internal PKI entitlement from the effective /v1/activate and /v1/check response rather than forcing it on from the Enterprise tier name. The normal refresh is every 15 minutes, and Settings > Product licence > Refresh authority pulls an immediate effective entitlement without restarting SSL Nexus.

Two ACME Roles In SSLNexus

Do not confuse the private CA with the normal ACME provider adapters. With Let’s Encrypt, DigiCert ACME or Custom ACME, SSLNexus is an ACME client consuming another CA. With Internal PKI, SSLNexus is the ACME certificate authority and your internal systems are the clients.

Activate Internal PKI

1. Open Settings > SSL Nexus Internal ACME CA.
2. Enable the private CA and choose the CA name before first activation.
3. Set the maximum issued-certificate validity from 1 to 397 days.
4. Keep Require External Account Binding (EAB) enabled.
5. Save and allow the service to restart.
6. Open Internal PKI from the dashboard navigation for ongoing administration.

First activation creates an ECDSA P-256 private root in /var/lib/ssl-nexus/internal-acme. Protect this state as part of normal Backup & restore.

Published Endpoints

ACME directory  https://<ssl-nexus-hostname>/acme/internal/directory
Root CA         https://<ssl-nexus-hostname>/acme/internal/ca.pem
CRL (DER)       https://<ssl-nexus-hostname>/acme/internal/crl
CRL (PEM)       https://<ssl-nexus-hostname>/acme/internal/crl.pem

New leaf certificates contain the DER CRL URL as their CRL Distribution Point.

Internal PKI Management

The Internal PKI page is the operational control surface after activation. It shows the root identity, SHA-256 fingerprint and expiry, directory/root/CRL URLs, enrollment policies, ACME accounts, account last use, issued private certificates and revocation state.

Internal PKI certificates are also mirrored into the normal Certificates estate with provider internal_acme and deployment mode acme_pull. Their renewal is intentionally marked client-managed because the ACME client owns the renewal transaction.

Create An Enrollment Policy

Administrators create enrollment policies before a new ACME client registers. Each policy defines:

• a recognisable owner/name;
• general or network scope;
• exact DNS names and/or delegated subdomains such as *.apps.internal.example.org;
• optional allowed source CIDRs;
• RSA, ECDSA or both;
• minimum RSA key size;
• maximum leaf validity;
• maximum ACME account count.

External Account Binding

Creating an enrollment returns an EAB KID and EAB HMAC secret. The HMAC secret is shown only at creation or secret rotation time. Configure those values in the intended ACME client or automation secret store.

At new-account registration SSLNexus verifies the EAB signature, enrollment enabled state, source-network policy and account limit before accepting the client. If a reverse proxy sits in front of Internal PKI, configure its network under Settings > SSL Nexus Internal ACME CA > Trusted reverse-proxy CIDRs; otherwise SSL Nexus ignores forwarded client-address headers. If the credential is exposed, rotate the enrollment secret and disable any ACME accounts that are no longer trusted.

ACME Account Governance

The account table shows which enrollment owns an account, its scope, contact values, creation time, last use and status. Disabling an account blocks authenticated ACME use without deleting certificates previously issued to it.

Accounts created before EAB policy support remain visible to administrators as Legacy pre-EAB. Replace them with governed EAB enrollment and disable the legacy account when migration is complete.

Issuance Flow

1. The client registers an account using EAB.
2. The client creates an order for one or more permitted DNS names.
3. SSLNexus returns HTTP-01 challenges.
4. The client publishes each token at http://name/.well-known/acme-challenge/token.
5. SSLNexus validates the challenge and enrollment policy.
6. The client submits its CSR. The private key remains on the client.
7. SSLNexus verifies the CSR names/key policy, signs the leaf and returns the PEM chain.
8. The client installs/reloads the local service and later performs normal ACME renewal.

HTTP-01 Requirements

For each requested name, the SSLNexus controller initiates validation and must be able to retrieve http://<requested-name>/.well-known/acme-challenge/<token>. DNS resolution alone is not enough: routing, proxies, web-server authorization and TCP/80 from SSLNexus to the requested endpoint must allow the exact challenge path.

Distribute Private Trust

Certificates from Internal PKI are private and are not trusted by public operating systems or browsers automatically. Download the root from Internal PKI and distribute it only through your established trust-management controls, such as Active Directory Group Policy, Intune/MDM, Linux configuration management, appliance trust stores or application/JVM stores.

Revocation And CRL

Operators and Administrators can revoke issued private certificates from Internal PKI. Network Operators can revoke only network-scoped private certificates. ACME clients can also call the standard revokeCert endpoint for a certificate belonging to their own account.

Revocation updates the Internal PKI record, mirrored central certificate record and Activity & audit entry, then publishes the serial in the signed CA CRL. Revocation does not automatically remove a certificate from an appliance or application, so normal replacement still needs to occur.

Roles

• Administrator: activates/configures the CA, creates/rotates/enables enrollment policies, manages all accounts and revocation.
• Operator: can review Internal PKI, manage enrolled accounts and revoke certificates but cannot change enrollment-policy boundaries.
• Network Operator: can view/manage accounts and revoke certificates only where the enrollment has network scope.

Audit And SIEM

Account creation, orders, HTTP-01 validation success/failure, issuance and revocation are written through the normal SSLNexus Activity & audit path. Where audit forwarding is configured, the same events flow to the SIEM destination.

How This Differs From Push Deployment

Internal ACME is client-pull: the internal device owns key generation, renewal timing and local installation. First-party Deployment Targets such as IIS, Nginx, F5 BIG-IP, Palo Alto and VMware are managed push/orchestration: SSLNexus owns the remote workflow. Certificate destinations are a third mechanism that publish managed material into Vault, AWS Secrets Manager or Azure Key Vault.

Backup, Downgrade And Root Rotation

Protect /var/lib/ssl-nexus/internal-acme because it contains the private root and PKI state. A tier downgrade or explicit feature disable is non-destructive: state and existing certificates remain, but new Internal PKI protocol/management activity requires the effective Internal PKI entitlement.

Changing the CA display name does not replace the existing root. Root rotation is deliberately not a one-click action because it changes the trust anchor. Plan a root migration together with trust distribution and certificate replacement.

Current Protocol Boundary

R14 supports EAB account registration, scoped enrollment policy, HTTP-01, non-wildcard DNS names, RSA/ECDSA policy, CSR finalisation, PEM chain retrieval, account disable, certificate revocation, signed CRL publication, central inventory mirroring and audit/SIEM integration.

DNS-01, wildcard leaf issuance, OCSP and automatic endpoint trust-store deployment are not part of this revision.