FAQs
Frequently Asked Questions (FAQs)
Section titled “Frequently Asked Questions (FAQs)”General
Section titled “General”Q: Does SSL-CLM replace my Certificate Authority (CA)?
A: No. SSL-CLM is a manager (RA, Registration Authority). It talks to your CA (DigiCert, MSCA) to get certificates. It replaces the spreadsheet, not the CA.
Q: Can I manage certificates generated outside of SSL-CLM? A: Yes! Our Discovery engine finds existing certificates on your network and imports them into the inventory for tracking and alerting.
Q: What happens if the SSL-CLM server goes down? A: Your existing certificates continue to work. SSL-CLM is out-of-band; it is not in the traffic path. However, you will not receive expiry alerts or be able to issue new certificates until the service is restored.
Security & Compliance
Section titled “Security & Compliance”Q: Where are private keys stored? A:
- On-Premise Agents: Keys are generated locally on the target server (e.g., IIS) and never leave that machine.
- Java Keystores/Load Balancers: Keys are generated in memory by the Agent/Backend and securely pushed to the target.
- Database: If keys must be stored (e.g. for PFX download), they are encrypted at rest using AES-256.
Q: Does SSL-CLM support Hardware Security Modules (HSMs)? A: Yes. The Backend can communicate with Thales, Entrust, and AWS CloudHSM via PKCS#11 to protect the master encryption key.
Q: Can I restrict who can see private keys?
A: Yes. Role-Based Access Control (RBAC) allows you to define strict policies. For example, the Auditor role can see certificate metadata but cannot download the PFX or private key.
Technical & Networking
Section titled “Technical & Networking”Q: Does the Agent require root/admin privileges? A: It depends on the use case.
- Windows (IIS): Yes, it needs Local Admin rights to interact with the Windows Certificate Store and bind certs to IIS.
- Linux: Ideally yes, to restart web servers (Nginx, Apache). However, it can run as a standard user if it only needs to write files to user-owned directories.
Q: What ports need to be open? A:
- Agent -> Backend: Outbound 443 (HTTPS).
- Backend -> CA: Outbound 443 (to DigiCert/Sectigo API) or DCOM (to internal MSCA).
- Inbound: NONE! You don’t need to open any inbound firewall ports on your Agent servers.
Q: Does SSL-CLM support IPv6? A: Yes, both the Backend API and the Agent scanning engine fully support IPv6.
Integrations
Section titled “Integrations”Q: Can SSL-CLM manage load balancers like F5 BIG-IP? A: Yes. We have a native connector for F5 BIG-IP (iControl REST API) and Citrix NetScaler (Nitro API). The Agent pushes the certificate and updates the Client SSL Profile.
Q: How do you handle AWS ACM (Certificate Manager)? A: We integrate with AWS ACM to discover certificates. For private certificates, we can issue them and import them into ACM for use with ELBs and CloudFront.
Q: Do you support ACME? A: Yes, in two ways:
- ACME Client: We can request certs from Let’s Encrypt.
- ACME Server: We can act as a private ACME server, allowing tools like
certbotto request certificates from your internal MSCA.
Operations
Section titled “Operations”Q: How often does Discovery run?
A: Network scanning is resource-intensive, so it typically runs nightly. CA Sync (API pull) is lightweight and runs every 1-4 hours. Intervals are configurable in application.properties.
Q: What is “Canonical Inventory”? A: A certificate might be found by a network scan on port 443 and by syncing your DigiCert account. SSL-CLM merges these two findings into a single record to avoid duplicates, giving you a holistic view of that certificate’s locations.