TLS/SSL Certificates and Jefferson Lab

Jefferson Lab uses a variety of certificates for various purposes. Some are purchased from a commercial certificate provider which are pre-trusted in virtually all browsers and other software. Others are issued by the lab's Enterprise PKI. This page provides instructions for manually installing certificates needed to interact with Jefferson Lab systems safely and securely.

Instructions for Specific Systems

Commercial Certificates

For several years, our primary source for such certificates has been Verisign which was purchased by Symantec, which was recently re-sold to DigiCert. We are phasing out these certificates and are now using Network Solutions as our provider of commercial certificates.

Enterprise PKI Certificates

In addition to commercial certificates, JLab also maintains our own enterprise PKI which is used to issue certificates for many purposes. These certificates are identical to those provided by commercial Certificate Authorities ("CAs"), but they are not pre-installed (trusted) in browsers and other software. To establish trust for certificvates issued by our PKI, the root signing certifcate must be installed into software. Once that is done, certificates issued by our PKI can be used without encountering warnings regarding "untrusted" or "self-signed" certificates generated by most applications. Installation of this certificate is performed automatically on JLab managed systems, but can be installed manually for other equipment.

"Self Signed" vs "Enterprise" Certificates

Many systems can generate their own certificates, digitally signed using their own key. Such certificates are difficult to manage and importantly do not provide any means for revocation ("un-trusting") them in the event that their keys are compromised. Unfortunately, a lot of software as well as much of the information on the internet does not differentiate between such self-signed certificates and those NOT issued by a commercial CA (like an enterprise PKI). If your software complains about the certificate on any JLab service using such terminology, it is likely that installation of our root signing cert will correct this problem.

Jefferson Lab Root Certificate Authority -- Client Instructions

JLab maintains its own Certificate Authority to create and sign TLS/SSL certificates used to secure connections to numerous web and other network services. You must install JLab's signing certificate into your web browsers, email, and other clients that use TLS/SSL for secure connections. Without installing this certificate, some clients may generate warnings, while others may simply not connect.

JLAB Managed systems receive the JLab root certificate by default and place it in the system-wide certificate trust store, Firefox' trust store, and the trust store associated with the primary Java JVM installation (Java OpenJDK installation on Linux -- the Oracle JVM trust store is not automatically maintained). Most applications use these trust stores and so should not generate warnings regarding JLab issued certificates. For applications that do not use these certificate repositories, or that fail to receive the certificate automatically, users can install the certificate manually.

Note: Some programs give you the option of adding an exception, or otherwise ignoring whatever warning condition is detected. Such exceptions should never be made unless you are very certain that the exception is safe. A far better approach is to install the JLab root certificate so that your system or application will accept certificates issued by JLab by default.

JLab Root Signing Certificate

The certificate file that must be installed is available via the link below. Its identifying "fingerprint" (also, occasionally called the "thumbprint") is also provided. When installing/trusting any certificate, its fingerprint should be confirmed using a trusted source to insure the certificate is not forged.
  Depending on the program, the fingerprint is sometimes shown with colons between
  each pair of digits. This does not constitute a mismatch, it is simply 
  an attempt to make it easier to read.
  Both of the links above are for the same certificate in two different formats. You only
  need one or the other in any single system or application. Both formats are provided to make it 
  easier in cases where you have a system that prefers one format over the other.
Note: For convenience, the root certificate file is also available at


Instructions are provided below for Thunderbird, and several common web browsers -- Firefox, Internet Explorer and Chrome. Instructions are also provided for subversion. Instructions for other applications will be added if needed.

Step 1 -- Download and save the certificate for installation

Most web browsers allow you to doanload and open certificate files in one step, and then provide the option to install the certificate if desired. For other applications, you will need to download and save the certificate file on your system, and then install it into the application.

Step 2 -- Install the certificate in Common Applications

Install the certificate in Firefox

Assuming you are viwewing this page in Firefox, the certificate can be installed directly (without first saving it to a file on your system).


If you use Thunderbird as an email client, you must first download and save the certificate file as described in step 1. Then, the filel is installed into Thunderbird using the steps below. Upon completion of the steps above, Thunderbird should now happily connect to JLab TLS/SSL-enabld mail servers without generating warnings. If you get any warnings or errors from here on, they should be reported and the cause found and fixed.

Microsoft Edge

Edge is Microsoft's new web browser that is available in Windows 10. For JLab Domain Windows systems, the certificate shoudl be installed by default, so you should not need to perform these steps.

When you click on the certificate link provided above, Edge will download the file by default and save it in your Downloads directory. Once the donwload is complete, you should get a dialog bar at the bottom of the browser windows askign whether you wish to open the file or View Downloads.

Internet Explorer (IE)

With IE, when you click on the URL link above, you will get a dialog asking to open or save the file.


Chrome on Windows uses the same certificate store as IE. So, if you've installed the certificate for Internet Explorer, it should already be available to Chrome. If you use Chrome but not IE, the process of installing it is similar. Chrome on mobile devices uses a different strategy and you shoudl refer to the notes on Mobile devices below.

Safari (Mac OS X)

Safari uses the System Keychain for trusted root certificate authorities. You need to install the certificate into this Keychain and mark it as trusted.

Installing the JLab Root Certificate for Mobile Devices

Mobile devices vary widely from one OS (Android, iOS, Windows Phone) to another and even from one version or manufacturer to another. For example, the process is quite different for Android Lolipop vs. Marshmallow, or for Android Marshmallow on a Samsung phone or tablet than on an LG model (for example) running the same OS version. In many cases, however, clicking the link above to download the desired certificate, then opening the certificate on the device will perform the installation.

Android General Remarks

For Android based mobile devices, installing a trusted root certificate normally requires you to download and save the desired certificate onto the device's SD card or internal storage, then invoke a process to install the certficate from storage. For details, you will need to refer to your specific device/version documentation, or search for the process details on the internet.

iOS (iPhone, iPad) General Remarks

Browse to this site on the iOS Device that you want to install the certificate on, then follow these steps:

Windows Phones and Tablets

For Windows tablets like the Microsoft Surface Pro and others that run Windows, the process is identical to that described above for IE, Edge, Firefox, etc. If these devices are JLab owned (and therefore required to be members of the JLab Windows Domain), installation of the certificate should be automatic. For Windows Phone and similar devices (that do not run the full Windows OS), installation can be performed by tapping the link to download and save the certifciate, then tapping the downloaded file to initiate the installation process.

Installing the JLab Root Certificate into your Subversion Configuration

By installing the JLab root certificate into your subversion configuration, subversion will inherently trust certificates that are issued by the JLab PKI as long as they match the name you asked to connect to, they are within their validity period and have not been revoked (assuming your subversion client performs revocation checking). This is useful since certificates expire and must be replaced from time to time and such changes will trigger warnings if you explicitly trusted the individual server certificate previously by telling subversion to accept the certificate permanently.

Important Note: Subversion server certificates are transitioning from JLab PKI certificates to a commercial certificate issued by Network Solutions ("USERTrust") in 2017/2018. Once existing JLab certificates are replaced with the commercial certificate, the steps below will not be required and subversion client should implicitly trust the commercial certificate. The table at the bottom of this section provides the information eeded to verify the certificate presented by each subversion server as well the status of each -- whether it is using a JLab or commercial certificate.

To install the jlab root certificate into subversion --

Connecting Without Installing the Jlab Root Certificate into Subversion

If you do not install the JLab root certificate in your Subversion configuration, when you connect to an https-based subversion server URL, the client will inform you that
Error validating server certificate for '':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: someserver
 - Valid: from Mon, 11 Jul 2016 13:04:04 GMT until Tue, 09 Jul 2019 16:26:29 GMT
 - Issuer: jlab, org
 - Fingerprint: <hex fingerprint>
(R)eject, accept (t)emporarily or accept (p)ermanently?

You can choose to reject the connection, or accept it temporarily (for this session only), or accept it permanently. The last option stores the certificate into your subversion configuration so that if you connect to the same server again, you will not be prompted.

The fingerprint given is the fingerprint of the subversion server"s certificate -- not of the root certificate provided above. So, you should compare the thumbprint provided to the thumbprint below for the particular server you are connecting to.

SHA1 Fingerprints for current certificates of JLab https subversion servers is provided below

Subversion ServerCert ProviderCertificate Fingerprint
svncccNetwork Solutionsea:b8:32:18:82:a2:99:63:a2:c1:6e:ac:ca:d9:61:13:55:3c:e8:e9
qweaksvnNetwork Solutionsea:b8:32:18:82:a2:99:63:a2:c1:6e:ac:ca:d9:61:13:55:3c:e8:e9
jlabsvnNetwork Solutionsea:b8:32:18:82:a2:99:63:a2:c1:6e:ac:ca:d9:61:13:55:3c:e8:e9