Pre-discovery phase
Summarize
Summary of Pre-discovery phase
The pre-discovery phase prepares the environment for certificate discovery by defining scanning parameters and configuring credentials. This ensures a smooth start to the discovery process, focusing on gathering essential certificate data from various sources.
Show less
Key Features
- Discovery via Ports: The MID Server uses the
tlssslcertsport probe to scan 14 default ports (e.g., 443, 8443) to collect certificate information, which is then transformed into an XML payload for processing. - Discovery via URL: The
sndiscocertmgmtcerturltable holds target URLs for discovery. TheCertificateDiscoveryFromURLScanprobe retrieves certificate chains for these URLs and stores them in thesndiscocertmgmtcertificatehistorytable. - Import Certificates: The Import SSL Certificate pattern gathers certificates based on specified parameters like host name and folder location. It is critical to manage payload size to avoid memory issues.
- Discovery via CA Authority: With CA credentials configured, the system can execute REST API calls to CAs (e.g., GoDaddy, DigiCert) to collect certificate data and store it in relevant tables.
Key Outcomes
After completing the pre-discovery phase, you will be ready to initiate the post-discovery phase. Proper configuration will streamline the process of capturing and managing certificates, enhancing overall visibility and control over your SSL/TLS assets. This setup is essential for maintaining security and compliance in your certificate management strategy.
The pre-discovery phase involves preparatory steps, such as defining scanning parameters and configuring credential details, to ensure a smooth initiation of the certificate discovery process.
Discovery via Ports
- Typical ports for SSL: 443, 8443, 9443, 636 (ldaps), 993 (imaps), 995 (popssl), 989, 990
- StartTLS ports: 25 (smtp), 110, 143, 389, 21, 587 (smtp)
As part of the CI Discovery process during Shazzam, the MID Server uses scanners to gather certificate chain information from the IP port number, capturing diverse attributes, including the certificate hierarchy. The MID Server then transforms these certificates into an XML payload, sharing it with the instance. The Shazzam sensor, in turn, detects the ECC queue entry and inserts a new record into the Discovered Certificate table [sn_disco_certmgmt_certificate_history].
The following fields are pulled from the XML payload and verified in java code from the Shazzam TLS port probe for discovered certificates: certificate id, revocation_status, subject, issuer, sans/, is_self_signed, is_ca, valid_from, valid_to, signature_algorithm, fingerprint_algorithm, key_size, serial_number, and version.
Discovery via URL
The Certificate URL [sn_disco_certmgmt_cert_url] table holds a list of URLs to target for certificate discovery. Each record also has an optional reference to the Unique Certificate [cmdb_ci_certificate] table, to see what certificate is related to the given URL definition. The necessary parameters from the Discovery Schedule are combined to create and initialize the Discovery status. The [CertificateDiscoveryFromURLScan] probe discovers the certificate chain for each of the URLs in the batch and outputs an XML payload that contains the certificate chain for each certificate. It also adds a new record into the Discovered Certificate [sn_disco_certmgmt_certificate_history] table.
Discovery via Import Certificates (Version 1.1.7 Certificate Inventory and Management)
- Host name/IP where the certificates are hosted
- Folder where certificates are located
- TLS_keepOriginalCertificate: Setting this parameter to true may lead to increased payload size, potentially causing out-of-memory issues.
- Mid_temp_folder: The temporary folder on the MID Server where files will be temporarily copied.
Discovery via CA authority (Version 1.1.7 Certificate Inventory and Management)
Once the Certificate Inventory and Management credential is set up with either GoDaddy, DigiCert, Entrust, or Sectigo Certificate Authority and the Discovery schedule runs, the specific CA pattern makes REST API calls to (GoDaddy, DigiCert, Entrust, or Sectigo), collects certificate information, retrieves the list of certificates, and stores it in the [cmdb_ci_certificate], [certificate_domain], and [sys_attachment] tables.
- DigiCert - Certificate Management (ca_api_version = v2, ca_api_url = https://www.digicert.com/services/)
- Entrust - Certificate Management (ca_api_version = v2, ca_api_url = https://api.entrust.net/enterprise/)
- GoDaddy - Certificate Management (ca_api_version = v1, ca_api_url = https://api.godaddy.com/)
- Sectigo - Certificate Management (ca_api_version = v1, ca_api_url = https://cert-manager.com/api/ssl/)
- Start_offset: The offset position for reading certificates from CA authorities, with a default value of 0.
- Limit: The number of certificates to be read from the start_offset, with a default value of 1500.
- CredentialAlias: The name of the Credential Alias or Tag linked to the CA credentials, added in the serverless execution pattern configuration.
If the TLS_keepOriginalCertificate parameter is set to true, the certificate file is attached to the Certificate CI. This may increase payload size, potentially causing out-of-memory issues.
- IncludeCertStatus: A parameter for specifying additional certificate states to discover, in addition to the defaults.
You can include multiple certificate statuses by separating each with commas.Table 1. Certificate states by certificate authorities Certificate Authority Default States Discovered Sectigo - Issued
- Expired
DigiCert and GoDaddy - Active
- Expired
- Revoked
- Canceled
Entrust - Active
- Expired
- Revoked
Once the pre-discovery phase is completed, move on to the post-discovery phase.