The ICSI Certificate Notary

Much of the Internet’s end-to-end security relies on the SSL protocol, along with its underlying X.509 certificate infrastructure. However, the system remains quite brittle due to its liberal delegation of signing authority: a single compromised certification authority undermines trust globally. The ICSI Notary helps clients to identify malicious certificates by providing a third-party perspective on what they should expect to receive from a server. While similar in spirit to existing efforts, such as Convergence and the EFF’s SSL observatory, our notary collects certificates passively from live upstream traffic at multiple independent Internet sites, aggregating them into a central database in near-realtime.

Last updated:


  1. News
  2. Latest Blog Posts
  3. Usage
    1. Examples
    2. Auxiliary Interface
  4. Background
  5. How it Works
  6. Contact and Contributing
  7. Statistics
    1. Connection Cipher Details
    2. Certificate Public Key Details


Latest Blog Posts


The ICSI Notary provides a public DNS interface to query its database. To request information about a certificate clients can send a DNS request to the following domain:


The token <sha1> represents the SHA1 digest of a certificate (as, e.g., included in the information browsers report about SSL sessions). Our DNS service operates in two modes which employ A and TXT records respectively. In both modes, an answer of NXDOMAIN indicates that none of our data providers have encountered a certificate with the given digest.

For A record queries that have an associated entry, the notary answers with either to indicate that we have seen the certificate, or with if we can establish a valid chain to a root certificate from the Mozilla root store.

For TXT record queries, the notary replies with more details that come in the format of space-separated key-value pairs. We currently support the following keys:

An exemplary response for the digest C1956DC8A7DFB2A5A56934DA09778E3A11023358 may look like this:

version=1 first_seen=15387 last_seen=15646 times_seen=260 validated=1

We note that we log notary accesses for statistical purposes. However, our use of DNS provides clients with anonymity: when sending a recursive request to our DNS server, we only see the resolver’s IP address but not the one of the querier. If users want to avoid any evidence of their location, they can switch to public DNS services, such as OpenDNS or Google’s public DNS.


Auxiliary Interface

In addition to the primary interface described above, we also offer a DNS interface compatible to Google’s (now defunct) Certificate Catalogue. The domain <sha1> serves TXT records containing three space-separated values of the form first_seen last_seen times_seen with the fields having the same meaning as discussed above. For example, querying for the digest ...D534 returns the answer 15387 15646 260.


The Secure Socket Layer (SSL/TLS) protocol serves as a centerpiece of the Internet’s end-to-end security, providing secure encrypted channels and authentication through its underlying X.509 certificate infrastructure. In a nutshell, X.509 certificate authorities (CAs) sign SSL server certificates, which clients then verify against a list of trusted root CA certificates that ship with their operating system or client software. Unfortunately, this system is quite brittle due to its liberal delegation of trust. All root and intermediate CAs share the authority to sign any certificate Internet-wide. Hence, the compromise of a single intermediate undermines the entire X.509 certificate infrastructure, rendering CAs an attractive target for attackers.

As demonstrated by several recent high-profile incidents, an attacker typically acts as a man-in-the-middle (MITM) to assume the identity of a well-known secure site (e.g., a bank or email provider) by serving a malicious certificate. From the victim’s perspective, the presented certificate validates correctly against their root store and hence the attack goes unnoticed. While the weaknesses of the current state have been widely acknowledged, there is no real solution in sight. The security community has proposed a number of alternative PKI architectures (e.g., EFF’s Sovereign Keys, Google Transparency); however, widespread adoption remains unlikely for the medium-term future due to the fact that both clients and servers would have to support a new system.

SSL notaries represent an alternative approach to improve the existing state without architectural changes. A notary maintains a third-party database of known server certificates. When clients encounter a certificate, they can match it against the notary’s version and flag mismatches as possible attacks. Notaries represent an attractive extension to the existing X.509 architecture as they introduce a non-obtrusive reputation scheme into the standard validation process. Perspectives pioneered this method and Convergence provides an improved implementation.

Our work follows this approach by offering a novel notary service for SSL clients. However, while existing notaries build their certificate databases actively—by either scanning the IP address space from different vantage points, or by asking users to submit what they see—we passively extract X.509 certificates from live network traffic as observed on an ongoing basis at operational sites. As such, our notary complements existing services by providing a near real-time perspective on certificates in actual use by a large client population, along with further reputation information such when we first observed a specific certificate and the number of sites that have reported it.

How it Works

Data collection process

To feed our notary service, we are currently working with about 10 organizations that have instrumented their border gateways with our monitoring infrastructure, uploading all certificates they see to a central system at the International Computer Science Institute in near real-time. We use the open-source Bro network monitor to extract certificates from all SSL connections, independent of the transport-layer ports. To avoid revealing information about the collecting site, we only inspect outgoing connections, and we do not record any information that would directly identify a client system. We implemented the SSL analysis as a Bro script that we give operators at participating sites.

DNS architecture

When a site uploads data to our institute, we first import it into a database residing in an internal network. We exclude non-web certificates (e.g., Tor and Grid activity) and then generate a text zone file in DNSBL format on an hourly basis that we transfer over to the externally visible system located in a DMZ. We serve the zone file with an enhanced version of rbldnsd, a stripped-down, high-performance DNS server commonly used for high-volume blacklist-style information.

Contact and Contributing

Feel free to contact us for questions and feedback at We are looking forward to hear about applications making use of the provided DNS interface. We are also seeking further sites to include into our data collection; please let us know if you may consider contributing data to the ICSI Notary.


Connection Cipher Details

The following graph shows the most-used cipher-suites that we saw being used in all connections in the last 30 days.

Certificate Public Key Details

The following graphs show statistics about the public keys contained in currently valid certificates.