CameraStack TLS Manager configures and checks HTTPS on ONVIF cameras. It can manage a simple self-signed certificate, enrol a camera-held key with your certificate authority, verify secure media transports, and clean up unused objects created by CameraStack TLS tools.
The application never exports a camera private key. It keeps HTTP enabled while setting up or rotating a certificate. Disabling HTTP is a separate action with its own confirmation and recovery checks.
Start here
- Choose Discover cameras, then select the camera. You can also enter its ONVIF device-service URL.
- Enter an administrator username and password in the fixed left panel.
- Choose Inspect TLS. Inspection reads the current state and changes nothing.
- Pick the flow below that matches the inspection result.
Key generation can be slow on camera processors. Key wait (seconds) defaults to 180. Increase it if the camera is known to take longer. Every desktop action has an overall five-minute safety limit.
Self-signed certificate flow
Use Self-signed setup for a camera network where clients accept an exact certificate pin instead of relying on a certificate authority.
Camera has no active TLS assignment
- Leave Common name blank to use the selected camera name or address, or enter the stable DNS name clients use.
- Add every stable DNS name and IP address clients use.
- Choose Create, renew, or verify.
- Check and accept the displayed SHA-256 fingerprint.
The key remains on the camera. The manager checks the returned certificate, assigns it, enables HTTPS, and proves that HTTPS presents that exact certificate.
Camera already has one self-signed certificate
Use the same Create, renew, or verify action. It works regardless of which tool or administrator created the existing certificate.
- A healthy certificate outside the renewal window is verified without changing camera protocol settings.
- A certificate near expiry, expired, not yet valid, too weak, or using the wrong identity is replaced atomically.
- Select Replace the active self-signed certificate now for immediate renewal.
- Leave the Common name and SAN fields empty to preserve the existing identity details while also requesting the currently selected camera address.
Some cameras ignore requested subject alternative names. The default mode shows a compatibility warning when the common name still matches. Select Reject cameras that omit requested SANs when that behaviour is not acceptable.
Adopt current certificate
Adopt current certificate does not create, replace, assign, or enable anything. It verifies the certificate already presented by HTTPS, asks you to confirm its fingerprint, then stores that public certificate as the manager’s exact pin. Use it when another tool has already configured the camera.
Certificate authority enrolment
Use CA enrollment and rotation when clients should trust the camera through an organisational or private certificate authority.
- Enter the requested common name and SANs.
- Choose where to save the public CSR. The enrolment journal is stored in the operating system’s application data folder by default.
- Choose Create key and CSR.
- Give the CSR to your CA. Keep the journal on this workstation.
- When the CA returns the certificate, select the journal and a leaf-first PEM bundle.
- Choose Validate, activate, and verify and confirm the fingerprint.
The journal contains no password and no private key. It records enough non-secret state to resume an interrupted enrolment. TLS Manager detects an unfinished default journal when it starts.
TLS key choices for older and newer cameras
For self-signed setup, Automatic chooses P-256 when supported, then P-384, RSA-3072 or RSA-2048. A healthy existing certificate is verified and retained; the selection controls a newly created identity. Use forced renewal to change an otherwise healthy certificate’s key type.
CA enrolment defaults to RSA-2048 for compatibility and also offers RSA-3072, P-256 and P-384. Choose a profile accepted by your CA and other clients. The manager checks camera capabilities before key creation and verifies the returned CSR and issued certificate against that choice. The issuing CA may use a different key algorithm from the camera. Media Signing keeps its own RSA-2048 and P-256 choices.
Inspection shows the camera’s Add-on tokens. Older cameras need not advertise the new version 2.0 token to remain usable. Cameras that report a longer TLS setup time receive a bounded activation wait; missing or invalid estimates keep the existing 30-second allowance.
Verify secure transports
The Verify tab checks what the camera advertises, including authenticated ONVIF over HTTPS, certificate name and validity, workstation trust or exact pin, snapshots, secure RTSP variants, WebSocket transport, and supported TLS versions. An unsupported optional transport is reported separately from a failure.
The support ZIP contains a sanitised JSON report and text summary. It should not contain passwords, authentication headers, certificates, or media payloads.
Disable plaintext HTTP
Run Verify secure transports first. Disable plaintext HTTP becomes safe only when the secure management checks pass. The manager repeats the preflight, sends the change through verified HTTPS, waits for HTTPS to return, confirms the camera reports HTTP disabled, and requires three consecutive refusals from the old HTTP TCP port.
Do not use this action unless every management client can reach the camera over HTTPS and you have an out-of-band recovery method.
Cleanup and recovery
Preview cleanup lists unused paths, certificates, and keys carrying aliases used by either CameraStack TLS tool. Assigned objects and unrelated vendor or administrator objects are excluded. The preview is checked again immediately before deletion.
Remove every TLS server assignment is a recovery flow for starting again. It is available only through an enabled HTTP connection. It disables HTTPS, confirms over HTTP that the camera reports HTTPS disabled, removes the assignments, and retains certificate objects for inspection or later cleanup. Some cameras keep the old HTTPS listener reachable until they restart.
Prefer normal atomic renewal when one active assignment is usable.
Sign camera video
Open Media signing and choose Inspect media signing. The factory path identifies the camera maker’s provisioned identity. The optional user path identifies an organisation’s signing certificate. TLS certificates secure the connection; these assignments identify signatures carried with the video.
To use the factory identity, select a supported video encoder and choose Enable signing. Every profile sharing that encoder receives the setting.
For an organisation’s identity, choose an existing suitable certificate path and Assign selected path, or use Create or resume signing CSR. Send the exported CSR to your CA. Select the saved signing journal and the issued leaf-first certificate bundle including the CA root, then choose Import and assign signing certificate. The private key stays on the camera. A standalone self-signed TLS certificate is not suitable for this enrolment.
The default Automatic choice prefers a P-256 signing key when the camera advertises the complete ECC and CSR capability set, then falls back to RSA-2048. You can choose either explicitly.
The camera key and CA signature are different choices. P-256 here means the camera owns a P-256 private key. Your CA may still sign that certificate with RSA. Likewise, an ECDSA CA may sign a certificate containing an RSA camera key. The manager checks the camera public key against the saved CSR without assuming that the issuer used the same algorithm.
Choose a new journal file for each enrolment and keep it until setup finishes. If setup is interrupted, the application offers recovery for the saved stage. For a new journal, an interruption during key creation can be resumed with Resume preparation from the selected journal and Create or resume signing CSR. The manager inspects camera inventory before creating anything else. If it finds ambiguous objects, it stops for inspection. Older journals may lack enough evidence to recover this early stage; keep the journal and follow the reported inspection guidance instead of starting again blindly.
Resume recovers an existing key; it does not generate a replacement when the original key is absent. Review and archive that journal before beginning a new enrolment, because absence can mean that the camera was reset. If only the CSR file export failed, select the saved journal and choose Export CSR from saved journal to recover the same request without a new key.
Close signed viewing sessions before replacing or removing a user
assignment. Camera behaviour differs by specification version: 26.06
cameras reject an in-use assignment with ReferenceExists, while newer
cameras can accept the change and stop ongoing streams themselves. The
manager checks assignment readback in either case. Reconnect viewers
after the change if needed. Return to factory signing retains the
user certificates and resumes use of the factory identity for signed
encoders. Disable signing stops signing on the selected encoder.
These controls leave HTTP, HTTPS and TLS assignments alone.
The camera signs locally and does not contact the CA for each recording. A viewer still needs its own trust settings and video verification. A successful setup message here confirms camera configuration, not that video has been verified. If the camera does not advertise media-signing support, the setup controls remain disabled; its factory identity and signing-capable firmware must be provided by the camera maker.
Renew or replace a signing certificate
A certificate has an expiry date, but the private key does not. Renewal asks your CA for another certificate. Replacement also gives the camera a new key. Both operations prepare the new certificate before changing the active user assignment, so a CA delay does not remove the current signing identity.
- Choose Inspect media signing and confirm the current user assignment.
- Under Renewal key, choose Generate a new key (the default) or Reuse the assigned user key. Reuse applies only to a customer identity, never to the camera maker’s factory key. It is unavailable if the camera prohibits sharing a private key between certificates.
- Choose a fresh journal output file and Create or resume signing CSR. Send the exported CSR to your CA. A CSR contains the public key and a signature proving possession of the private key; it does not contain the private key itself.
- Select that saved journal and the CA’s leaf-first certificate bundle, including the root. Close signed viewing sessions before choosing Import and assign signing certificate.
- After successful verification, open Cleanup, select the enrolment journal, and choose Preview cleanup. Review the proposed deletions before applying them.
The Camera key choice applies when generating a new key. Reusing a key keeps its actual algorithm. A renewed certificate may reuse the same CA certificate already stored on the camera. Cleanup keeps that CA certificate, a reused private key, and any objects still used by TLS or another certificate path.
Automatic retirement is available only after a verified replacement recorded in a version 4 journal. The preview checks the exact saved certificate material, key bindings and ordered path contents against the camera. Shared or assigned objects remain in place. Ordinary cleanup without a journal leaves Media Signing objects alone.
For an older journal or unfinished enrolment, cleanup lists the remaining objects and archives the journal after your confirmation. It does not delete those camera objects. Use resume instead if you intend to finish enrolment. Archiving keeps the history but removes that journal from the pending-setup list; it is not a rollback or proof that the camera is empty.
A certificate binds a public key to a stored KeyID. Automatic cleanup uses that exact recorded certificate as evidence before deleting its key. If the certificate has already disappeared, or the bytes or key binding changed, cleanup retains the unprovable object. This applies equally to private camera keys and public issuer keys. It does not ask a key to sign a new CSR merely to prove that the key may be deleted.
The preview lists retained path, certificate and key IDs with a reason. Keep the archived journal for inspection. TLS Manager displays inventory but has no arbitrary manual delete controls; leftover objects need separate administration through the camera’s standard ONVIF deletion operations or another appropriate camera administration tool. A listed object may still be assigned or shared, so listing it is not a recommendation to delete it. Avoid concurrent administrative changes during cleanup; ONVIF deletion is not an atomic compare-and-delete operation.
After a camera reset
For CameraStack Server, Soft factory reset preserves network access settings and the security store, including TLS and signing credentials. User accounts return to the camera’s factory defaults, so the previous login may no longer work even though its address and TLS certificate remain the same. Enrolment can resume once its camera key was successfully generated. A reset or ordinary restart during key generation interrupts that operation; the camera marks the incomplete key unusable. Keep its journal, review the retained objects for manual handling, and begin with a new journal rather than silently creating another key. Hard factory reset removes customer keys, certificates and assignments, while retaining the provisioned factory signing identity. Signed encoder settings return to their factory defaults. Other ONVIF vendors may choose a different Soft reset policy.
A saved journal is evidence of earlier work, not permission to recreate it on a reset camera automatically. The manager checks the factory identity and customer objects before resuming. If Hard reset removed that customer state, archive the stale journal through Cleanup and start a fresh enrolment. If the factory identity changed or an object ID now identifies different certificate material, stop and inspect the camera before proceeding.
Reset and cleanup do not replace manufacturer provisioning. Factory-key rotation and recovery of an incorrectly provisioned factory identity remain separate deployment decisions.
Files and local secrets
- Passwords and accepted certificate pins are stored through the operating system credential vault when available.
- Enrolment journals are owner-only files in the application data folder by default.
- Exported public certificates and CSRs may be shared. TLS Manager atomically replaces regular output files and refuses symlink destinations.
- The camera private key is never written to this computer.
If saving an enrolment journal fails, keep the file and read the error’s object ID. The camera key, certificate or path is retained because the journal may already refer to it. Reload the journal and inspect the camera before retrying; do not start another enrolment blindly. Cleanup stops if it cannot determine which certificates are still assigned.
Support
When reporting a problem, include the application version, camera manufacturer, model and firmware, the action attempted, and a freshly generated sanitised support ZIP. Do not send camera passwords.