DANE Patrol

DANE Patrol is fork of Certificate Patrol which brings in implementation of RFC 6698 to validate SSL/TLS certificates. It also supports multiple certificates per host. TLSA can be turned off, which turns DANE Patrol in Certificate Patrol with support of multiple site certificates.


DANE Patrol is no longer mantained. The TLSA record verification feature has been implemented into DNSSEC Validator 2.1, which can be downloaded here. At the moment, the feature "override untrusted certificate page" is broken with DANE Patrol due to Firefox's very common API changes. One possible workaround is to uncheck "Allow certificate usage 2 and 3 to override untrusted certificates".


Currently the alpha version is built for Linux and Mac OS X (Windows build in progress).


Few DANE Patrol screenshots available here.

Source code

Code repository is available at:



Limitations and warnings

Do not install at the same time as Certificate Patrol (it may have strange side effects).

Do not use with Tor. The NPAPI plugin performs DNS queries which would not be tunelled. Alternatively select "Never check DANE TLSA records" in preferences which disables the DNS TLSA queries.

The "Reject" button will only reject to store the certificate, it can't abort connection immediately after SSL/TLS handshake. Similarly a bad TLSA (a MitM attack) will display a warning, but can't abort the connection before first request is made. This isn't such a problem for a toplevel site, but could matter for instance if bank's main site is bank.com, but login is posted to secure.bank.com through POST via a form on the page.

These above notes (sans TLSA stuff) apply to Certificate Patrol as well (haven't seen that described anywhere, found out when digging in code).

The click-to-play feature must be turned off, otherwise the TLSA fetcher plugin can't initialize.

Known bugs and quirks


Currently the build works on Linux and Mac OS X (Windows requires some extra hacking).

Build requirements

Build parameters of CMake

Toplevel CMake takes one parameter TARGET_ARCH which can be either i686 or x86_64. If not specified, cmake script will try to guess the arch based on current machine environment. This works fairly well for Linux, but for Mac there is a well-known bug of CMake reporting 32-bit arch even if machine is x86_64.

Thus in general the build is done by invoking CMake, then make (note the dot at the end of cmake invocation):

cmake [-DTARGET_ARCH=(x86_64|i686)] .
make [VERBOSE=1]

Do not mix builds for two architectures in one cloned repo tree (build system is not that far yet).

Build on Linux

Just call cmake and make without any extra parameters:

cmake .

Build on Mac

It is recommended to set explicitly the target architecture on Mac since CMake may guess it wrong (see above), e.g.:

cmake -DTARGET_ARCH=x86_64 .