- User Services
- Group Services
- Scientific Computing
- Copy Services
JLab Server Certificate Renewals -- possible connection problems for browsers, subversion clients, etc.
Submitted by email@example.com on Thu, 01/12/2017 - 11:30
A few months ago, TLS/SSL certificates for JLab internal web servers were renewed due to their imminent expiration. They are now (January/February 2017) being renewed again to upgrade them to use SHA2 Signatures, issued by our upgraded PKI. The use of SHA2 signatures for all end entity and intermediate certificates is required for all browsers and eventually other clients because the previous SHA1 signature algorithm has been effectively "broken" and is deprecated.
Automatic processes have already installed the new JLabCA root certificate on managed systems at JLab. This includes Windows domain members, Level I and II as well as "CUEified" Macs. The automated process installs the root certificate into the default locations on each platform (Windows, Linux and OS X) which makes it available to most applications on each platform, including Firefox/Thunderbird and the default Java JVM. For other applications which maintain their own key/certificate stores, users will need to install the new certificate manually.
Note that this change affects all JLab servers that use SSL/TLS, including those hosting subversion and other services. As a result, users may see warnings or failures to connect (depending on the configuration of the client application being used). To avoid these warnings, users must install the JLab PKI "root" certificate. Additional information regarding this issue and the root certificate and instructions for installing it are available at http://pki.jlab.org. As we transition all services to use these new certificates, client systems should install BOTH the new JLabCA root certificate as well as the legacy JLabWinCA root certificate.
Subversion Client Warnings
Several users have raised questions regarding the server certificates used on subversion servers recently. If the root Certificate is not installed in your subversion configuration, the subversion client generates a warning upon attempting to connect, and asks you if you wish to accept the certificate being used, either temporarily or permanently. To help you confirm that you are
connecting to the server you are expecting (that your connection is not somehow being spoofed or otherwise subverted), the client displays the server certificate's "fingerprint" so you can compare it to the official fingerprint for the server. It is recommended that users install the lab's root certificate into their subversion configurations. However, if that is not desired (non-JLab systems at other sites, etc. may have policies or practices discouraging or prohibiting this), the fingerprint can be used to verify the specific server's certificate prior to trusting it. Instructions for installing the root certificate, as well as the fingerprints of the lab's subversion servers can be found in the subversion section of our main PKI page.
The lab maintains its own Public Key Infrastructure that is used to issue and manage a number of certificates used in secure connections using TLS/SSL (like https://...). Certificates are used to identify the servers and establish an encrypted connection to insure the privacy of authentication and other information. Certificates have specific lifetimes or "validity periods". The certificates issued by the lab's PKI for the past several years use SHA1 based signatures. SHA1 is effectively broken and is no longer supported by browsers and other client applications and so must be replaced by new certificates using SHA2 signatures. This applies to certificates used by a number of the lab's internal web servers. Since intermediate CA certificates are also affected by this issue, and all new certificates use our new root Certificate Authority, the new JLabCA root certificate must be installed in your browser or applications attempts to connect will generate a warning indicating the certificate is insecure, or, in some cases, may simply refuse to connect.
The JLab PKI Hierarchy
Certificates for these servers are issued and signed by a JLab intermediate certificate authority which, in turn uses a certificate issued and signed by the Lab's "root" certificate authority. By installing the certificate for the JLab root CA, you allow your system to accept certificates issued by our Public Key Infrastructure as valid -- avoiding warnings/errors indicating that "you are attempting to connect to a server with a certificate issued by an unknown or un-trusted certificate authority" or something similar. Server certificates still must pass several other tests -- that the name on the certificate matches the name of the server you are attempting to connect to, that the certificate is within its validity period and that the certificate has not been revoked by the CA that issued it (assuming the client application is configured to perform revocation checking).