Availability

Satellites are available on Team, Business, and Enterprise plans. Solo users can manage certificates directly, but production Satellite workflows start at Team.

How it works

1. Install the SecuriTLS Satellite inside your environment.
2. The Satellite connects outbound to SecuriTLS.
3. SecuriTLS sends certificate, CRL, CSR, signing, or deployment jobs through that connection.
4. The Satellite performs the operation locally and returns status to SecuriTLS.

This avoids opening inbound firewall access from SecuriTLS to internal servers.

Satellite deployment

Satellites can deploy certificates, chains, CRLs, and private keys to SSH devices from inside your private network. This is useful for private infrastructure, segmented networks, and environments where direct public SSH access is not acceptable.

Private key custody

A Satellite can participate in two private-key custody models: Satellite-encrypted custody and HSM-backed custody.

The encryption and hsm configuration blocks are independent. Configuring an encryption provider does not configure HSM-backed custody, and configuring an HSM provider does not change how Satellite-encrypted keys are protected.

Satellite encryption providers

The encryption configuration controls how private keys using the Satellite encrypted custody model are protected.

Supported provider configurations include:

• Local encryption
• AWS KMS
• Azure Key Vault
• Google Cloud KMS
• HashiCorp Vault

Cloud-provider credentials should be supplied through the provider's normal environment-variable or workload-identity mechanism rather than embedded in the Satellite configuration file.

HSM-backed custody

HSM-backed custody keeps the private key outside SecuriTLS and outside the Satellite's encrypted key store. The Satellite sends key-generation and signing operations to the configured HSM provider and stores only the key reference required for future operations.

Because an HSM-backed private key is non-exportable from the SecuriTLS workflow, it cannot be deployed as a PEM private-key file. Certificate material can still be deployed independently where appropriate.

HSM configuration is defined separately from Satellite encryption using the hsm block.

KMIP HSM integration

Satellites can connect to compatible KMIP servers for HSM-backed private-key operations.

The current KMIP integration supports:

• KMIP version negotiation
• CreateKeyPair
• Activate
• Get public key
• Sign
• RSA 2048, 3072, and 4096-bit keys
• ECDSA P-256, P-384, and P-521 keys
• ML-DSA 44, 65, and 87

Other KMIP servers may also be compatible when they implement the required KMIP operations, key types, and signing algorithms. Unless explicitly listed as validated, compatibility should be verified in the target environment.

Configuration structure

A Satellite configuration contains the connection settings used to reach SecuriTLS plus optional encryption, import, and HSM settings.

{
  "url": "wss://example.securitls.com/ws/satellite/<endpoint-id>",
  "tlsSkipVerify": false,
  "jwt": "<satellite-token>",
  "rsaKey": "satellite.pem",
  "logLevel": "info",

  "encryption": {
    "provider": "local"
  },

  "hsm": {
    "provider": "kmip",
    "kmip": {
      "address": "kms.example.internal:5696",
      "serverName": "kms.example.internal",
      "clientCert": "./certs/client.pem",
      "clientKey": "./certs/client-key.pem",
      "caCert": "./certs/ca.pem"
    }
  }
}

The encryption provider is used for Satellite encrypted custody. The hsm provider is used for HSM-backed custody.

Local encryption

{
  "encryption": {
    "provider": "local"
  },
}

You can generate a new aes-256 key with satellite by running satellite -genkey

AWS KMS encryption

Supply AWS credentials using the standard AWS credential chain or environment variables. Do not place access keys directly in the Satellite configuration.

{
  "encryption": {
    "provider": "aws-kms",
    "awsKms": {
      "keyArn": "arn:aws:kms:us-east-1:123456789012:key/<key-id>"
    }
  }
}

Azure Key Vault encryption

{
  "encryption": {
    "provider": "azure-key-vault",
    "azureKeyVault": {
      "vaultUrl": "https://example.vault.azure.net",
      "keyName": "satellite-key",
      "keyVersion": "<key-version>"
    }
  }
}

Google Cloud KMS encryption

{
  "encryption": {
    "provider": "gcp-kms",
    "gcpKms": {
      "keyName": "projects/example/locations/us-east5/keyRings/pki/cryptoKeys/satellite"
    }
  }
}

HashiCorp Vault encryption

{
  "encryption": {
    "provider": "vault",
    "vault": {
      "address": "https://vault.example.internal:8200",
      "keyName": "satellite-key"
    }
  }
}

KMIP HSM provider

{
  "hsm": {
    "provider": "kmip",
    "kmip": {
      "address": "kms.example.internal:5696",
      "serverName": "kms.example.internal",
      "clientCert": "./certs/client.pem",
      "clientKey": "./certs/client-key.pem",
      "caCert": "./certs/ca.pem"
    }
  }
}

Mutual TLS credentials authenticate the Satellite to the KMIP server. The configured server must support the KMIP operations and algorithms required by the key being created or used.

Vault HSM provider

{
  "hsm": {
    "provider": "vault",
    "vault": {
      "address": "https://vault.example.internal:8200"
    }
  }
}

Cross Satellite workflows

If the certificate key and the signing CA key live on different Satellites, SecuriTLS can coordinate a CSR based flow. The certificate Satellite generates the CSR, and the signing Satellite signs the final certificate without receiving the subject private key.