CertControl-Probe in your logs.This page explains what CertControl-Probe is, who operates it, what it checks — and how to opt out with a single file if you prefer.
CertControl is a certificate management platform used by IT and security teams to monitor the TLS configuration of their own infrastructure. When a customer adds a hostname to CertControl, the platform periodically connects to that host to check certificate validity, expiry, and cipher suite quality.
The probe that reached your server was initiated by a CertControl customer who has added your hostname to their monitoring scope — because they own or operate it, or have written authorisation from the hostname owner to do so.
We operate under Danish law and EU regulations, including GDPR. We do not sell scan data or share it with third parties other than the customer who initiated the probe. Every probe is initiated by an authenticated customer who has agreed to our terms of service — not by us on our own initiative.
A standard TLS handshake to retrieve the certificate chain. Checks subject, issuer, validity dates, and chain completeness. This is equivalent to what a browser does to establish a TLS connection when a user visits your site.
Protocol: TLS. The handshake completes to retrieve the certificate; no application data is transmitted.
A series of TLS handshake attempts using known weak cipher suites — RSA key exchange, CBC-mode ciphers, SHA-1, and NULL ciphers. The probe checks which weak suites your server accepts, if any.
Tool: OpenSSL s_client. This is equivalent to what security tools such as Qualys SSL Labs or sslyze perform when testing server cipher support — not analogous to browser behaviour. 6 separate TCP connections, 350 ms apart.
A single HTTP HEAD request to check for security response headers: HSTS, CSP, X-Frame-Options, and X-Content-Type-Options. This is the same request any monitoring tool or browser preflight would make.
Method: HEAD. No body is sent or stored.
All probes originate from the following addresses. Add both to any allowlist:
187.124.178.220 (IPv4)
2a02:4780:79:4236::1 (IPv6)Dual-stack servers may receive the probe over either address. If your IDS or WAF generates alerts for CertControl traffic, allowlist both. We will publish a notice on this page if either address changes.
A full probe cycle generates at most 9 TCP connections to port 443, spread over approximately 3–4 seconds:
/.well-known/certcontrol-noprobe)The 350 ms pacing between cipher probes is deliberate — it keeps connections within separate 1-second buckets and reduces load on servers with tight connection-rate limits. Cipher probes use OpenSSL s_client with SNI. The TLS cert scan uses the Java (JSSE) TLS stack. No TLS session resumption is attempted — each probe is a fresh TLS handshake with no shared session cache. Both originate from the same source addresses.
HTTP HEAD and redirects: The HTTP security header check follows HTTPS redirects (HTTPS→HTTPS only; HTTPS→HTTP downgrade redirects are not followed). If a monitored hostname redirects to a different FQDN, the probe contacts that redirect target to retrieve security headers from the final response. Sysadmins on redirect destination hosts may therefore see CertControl-Probe in their access logs even if their hostname was not directly added to any monitoring scope.
Probes target port 443 by default. If a customer has registered a hostname with a non-standard port (e.g. host:8443), that port is probed instead. The opt-out file check always uses port 443 over HTTPS, regardless of the monitored port.
Opt-out applies per exact hostname (FQDN). Placing the file at example.com does not opt out api.example.com — each subdomain requires its own opt-out file. If you manage a large number of subdomains and want them all excluded, contact us directly.
If the opt-out check cannot complete (for example, because the hostname's certificate is expired), the opt-out is treated as absent and the probe proceeds. If you have an expired certificate and want to opt out, the direct contact route below is the most reliable option.
Opt-out and non-standard ports: The opt-out check always uses port 443. If a customer has registered your hostname with a non-standard port, placing the opt-out file at your port 443 root is still sufficient to stop all probing of that hostname.
All of this information is publicly observable — the certificate chain and cipher negotiation are exchanged before any encryption is established, and are visible to any client that connects to your server.
Scan results are stored exclusively in the CertControl instance belonging to the customer who initiated the probe. Results are not shared, sold, or published.
Publish an opt-out file at the path below and we will stop probing that hostname within one probe cycle under normal operating conditions — no registration, no forms, no notification required.
Place an empty file (or any file) at this path on your web server, accessible over HTTPS and returning HTTP 200:
https://yourdomain.com/.well-known/certcontrol-noprobeFor example, on a Linux server with nginx or Apache:
mkdir -p /var/www/html/.well-known
touch /var/www/html/.well-known/certcontrol-noprobeBefore each probe cycle, CertControl checks for this file. If it returns HTTP 200, that probe cycle does not proceed and scanning remains stopped for as long as the file is present. You do not need to contact us — the file alone is sufficient.
Shared hosting note: The opt-out mechanism relies on file presence at the web root. In environments where multiple parties can write to /.well-known/ on the same server, an unintended party could place this file and suppress monitoring of your hostname without your knowledge. If uninterrupted monitoring is critical, verify that your web root is not writable by co-tenants.
The opt-out file stops future probing. It does not affect scan results already collected and stored in the customer's CertControl instance. If you want previously collected data removed, contact us at certcontrol.pro/contact.html and we will process a deletion request. Scan results are automatically deleted after 12 months.
To have a specific hostname removed from a customer's scope, or to ask about a particular probe, contact us at certcontrol.pro/contact.html. We aim to respond within one business day.
Every probe is triggered by a CertControl customer who has agreed to our terms of service. Our terms explicitly require customers to only monitor hostnames they own or have written authorisation to monitor. Customers who violate this are subject to account suspension.
CertControl does not perform speculative or mass scanning. Probes only run against hostnames that a customer has explicitly added to their account.
For the external attack surface scanner feature, customers are required to prove control of a domain via a DNS TXT record or an HTTP verification file before scanning can begin. For standard certificate monitoring, authorisation is governed contractually through the terms of service.
Every check CertControl performs reads publicly available TLS configuration — we do not exploit vulnerabilities, attempt authentication, or modify any server state. The TLS certificate scan is equivalent to what a browser does to establish a connection. The cipher suite probe is equivalent to what security tools such as Qualys SSL Labs and sslyze perform when testing server cipher support.
Unlike Qualys SSL Labs, CertControl does not publish scan results in a public database. Results are private to the customer who initiated the probe and are never shared publicly. CertControl runs continuously on behalf of the system owner rather than as an on-demand public check.
Probes run at scheduled intervals suited to certificate monitoring — typically daily or weekly per hostname. This is deliberate: certificate states change slowly, and the platform is designed around that cadence, not around high-frequency sweeping.
We deliberately identify ourselves in the User-Agent string rather than masking our activity. A probe you can identify, understand, and opt out of is fundamentally different from one that hides its purpose. Transparency and responsible scanning practices are part of how we operate.
The processing of data during scanning is based on legitimate interests (GDPR Article 6(1)(f)). The legitimate interest is enabling our customers to monitor the TLS security of their own infrastructure. The data collected is limited to publicly available technical metadata — no personal communications, credentials, or user data are accessed.
Data controller: Certiva ApS, CVR 46450965, Denmark. Contact for data protection matters: certcontrol.pro/contact.html.
Scan results are stored within the customer's CertControl instance and are automatically deleted after 12 months. You have the following rights regarding data collected during probing:
For full details on how Certiva ApS processes personal data, see our privacy policy.
If anything about this probe is unclear, or you want to know what was checked and when — get in touch. We maintain full audit logs and can provide details on request.