DeepSurface: Certificates

Documentation
Installation Guide
Overview
Let DeepSurface Host For You
Getting Started
System Requirements
Self Hosted Quick Start - Installing to Cloud Platforms
Self Hosted - Installation Using an OVA
Registration, Package Installation, and Initialization
First Steps After Initialization of the Console
Deployment Options
Main and Subordinate Consoles
Agent-Based Deployment
User Managed Scan Deployment
Credentialed Scanning Deployment
Mixed Environment
Deployment Tools
Active Directory Group Policy
Microsoft Endpoint Configuration Manager (part of InTune)
Tanium Deploy
HCL BigFix
Ivanti
Virtual Machines
VMWare
Virtual Box
VirtualBox Guest Additions
AWS EC2 (BYOL)
AWS EC2 (Usage Based)
Azure Cloud
Google Cloud
Additional Items to Consider
Main Console Server Certificates
LDAP
TOFU
Clock Sync
DeepSurface Commands
Multiple Vulnerability Sources
API Documentation
User Guide
Reporting
Dashboards
Exports
Risk Insight
Hosts
Patches
Vulnerabilities
Vulnerability Instances
Users
Remediation Workflow Manager
Plans
Settings
Integrations
Workflow
Exporting
Accepted Risk Plans
Accepted Risk Workflow
Explore
Model
Paths
Activity
Tasks
Configuration Alerts
Scan Logs
Notification Settings
Scanning
Status
Agents
User Managed
Credentialed Scanning Settings
Credentials
Scan Groups
General Settings
Cloud Scanning
Network Connectivity
Subordinates
Vulnerability Sources
Setup
Sensitive Assets: Polices
Sensitive Assets: Manual
Admin Settings
SMTP Settings
Certificates
Outbound Proxy
Authentication Providers
Users
Tags
Integrations Guide
Vulnerability Sources
CrowdStrike Spotlight
SentinelOne
Carbon Black Cloud
Microsoft Defender for Endpoint
Wazuh
Lansweeper Cloud
Nessus API
Tenable.io API
Security Center/Tenable.sc API
Rapid7 InsightVM API
Qualys API
Nozomi Guardian
Eclypsium
AWS Inspector
Remediation
Jira Software
Tanium (BETA)
Authentication Providers
LDAP (Active Directory)
SAML (Azure Active Directory)
SAML (Google)
SAML (Okta)
PAM
CyberArk
Delinea (Thycotic)
Microsoft LAPS
Security Guide
Firewall Configuration
Base Network Requirements
Agent Network Requirements
Credentialed Scanning Network Requirements
API Network Requirements
How DeepSurface Scans Work
Domain (LDAP) Scanning
Host Scanning Routine
Reasons for the Administrative Access Requirement
Endpoint Protection Considerations
Other Items
Scope of Data Storage and Retention
IPS/IDS Considerations
Logging
Resetting the DSADMIN password
Product Information
Changelogs
Open source Licenses
End User License Agreement (EULA)

DeepSurface applies certificate validation to all SSL/TLS and HTTPS services it accesses. This validation can be performed in two ways:

1. CA certificates; or
2. Trust on First Use

Managing Installed and Discovered SSL/TLS Certificates

When DeepSurface communicates with various external services that leverage SSL/TLS to communicate, it must validate these certificates (just like a web browser would validate any site's HTTPS certificate). The services this applies to include those discovered during scanning (e.g. WinRM, LDAPS), configured APIs for third-party security products, and those used to secure communications with authentication providers. DeepSurface can validate certificates in one of two ways:

1. Traditional certificate authority (CA) based validation
2. Trust on First Use

The specific validation behavior varies from service to service and may be fine-tuned in some cases. TOFU is used only when traditional CA-based validation fails and the system is configured to fall back to TOFU. TOFU certificates are cached in the database and may be reviewed in the web interface. If a service's TOFU certificate changed for legitimate reasons, then DeepSurface will no longer be able to validate it, but administrators may remove or update the certificate in order to restore operation.

To review the certificates currently installed or cached, navigate to Setup > General Settings > Certificates. You will see a screen that looks like the following:

You can use the icons to download, view, add, edit, or delete a certificate.

The best way to ensure communications with external services continues uninterrupted over time is to obtain trusted certificates for every service and install them. If using an internal CA that your organization manages, we strongly recommend installing the CA certificate in DeepSurface so that internal server certificates can be validated without relying on TOFU. This reduces the long-term management overhead of DeepSurface and improves communications security.

DeepSurface supports local appliance authentication (through the DeepSurface Password Store) and Active Directory authentication brokered via the LDAP protocol. An "LDAP with NTLM" authentication provider must be configured to allow users to log into DeepSurface with AD credentials.

NOTES:

1. Once the LDAP with NTLM authentication provider is created, users must be created in DeepSurface in order for those users to be granted access.

2. DeepSurface usernames are case sensitive, regardless of authentication provider. While some authentication providers may allow case-insensitive names, the name a user types in at the login prompt must match the name and case of the user configured in DeepSurface.

3. A single configured LDAP with NTLM provider can support either a single domain, or multiple domains.

• If an authentication provider is configured with a blank “Windows Domain” field, then DeepSurface usernames must be configured with their Down-Level Logon Name (domain/username). This means users must then log in using exactly that string as their username.
• If the authentication provider is configured with a value specified in the "Windows Domain" field, then the user accounts created in DeepSurface for this provider should not include the domain name. In this case, users will login with their username. The domain name will be filled in using the authentication provider’s specified domain name.

SSL/TLS Certificates

In order to provide secure communications, most protocols use some form of TLS (or its predecessor, SSL). For example, HTTPS security is based on this. In order for this to work, TLS services must present a cryptographic certificate to TLS clients when they initially connect. TLS clients then validate the certificate is legitimate and continue the conversation over secure (encrypted and authentic) channel.

A critical part of the certificate validation process is for TLS clients to ensure they know the identity of the server, which is typically represented as a domain name. The certificate presented by TLS servers contains this domain name and is signed by a trusted certificate authority (CA). The TLS client must (amongst other things) trust the authority used, validate the cryptographic signature on the certificate, and validate that the entity it is communicating with matches the desired host.

Operating systems and browsers come shipped with a list of trusted certificates and CAs. As an example, you can find the list of certificates trusted by your web browser in the settings section under.

Firefox: Preferences > search for "certificate" in Find in Preferences Chrome: Go to Settings and search for "certificate" Safari: Go to Settings and search for "certificate" Edge (Based on Chromium): Go to Settings and search for "certificate" in the Search settings box

In cases where an organization's servers are not exposed to the internet, it can be more challenging to obtain a certificate signed by a trusted commercial/public authority. In this case, it is common for organizations to create their own internal certificate authority for the purpose of signing certificates used only by internal services. In order for this to work, all internal hosts which may interact with these services must have a copy of the internal CA's certificate installed.

Note: It is possible for services to be configured with "self-signed" certificates where there is no explicit certificate authority involved. However, this means TLS clients will typically be unable to validate the authenticity of the certificate, in which case the TLS communications are no more secure than using an unencrypted protocol. It is possible to use Trust on First Use mechanisms to partially mitigate this risk, but overall it is best to use certificates signed by an authority that is trusted by all TLS clients.

If you want to know more about TLS and HTTPS digital certificates, here are some helpful links:

HTTPS certificate page on Wikipedia

Certificate Authority

Trust on First Use

If TOFU authentication is enabled, then the first time a service is used, whatever certificate is provided will be recorded and used for future validation. After this first validation, if the certificate ever changes to a different, untrusted certificate, the connection will fail. There may be a legitimate reason the certificate changed. If you are confident you understand the reason, you can clear previously stored certificates in Administer > Certificates.

If an LDAPS or LDAP/StartTLS service presents a certificate that isn't signed by a known CA (e.g. a self-signed certificate), then DeepSurface will reject this certificate unless TOFU is enabled.

TOFU allows for a much simpler deployment while minimizing the window of opportunity for man-in-the-middle attacks. However, in high-security environments, DeepSurface Security recommends TOFU be disabled and that every service be configured with a signed certificate from a trusted CA.