In our daily affairs we sometimes need to deal with information that needs to be protected. That information can be personal, medical, academic or work related. The protection of some of this information is actually legislated by laws. Best practices dictate that we must protect sensitive data during the following stages:
Information is valuable depending on the type of data involved (personal, research data, corporate data, etc) and when it is not protected, it can be relatively to steal it as it travels over the internet or be stolen from repositories that are unprotected. Valuable information that falls in the wrong hands can cause significant damage to individuals, groups, organizations, governments and countries. If valuable information is encrypted at all the sensitive points, the stolen data becomes unreadable for the interceptor and this removes the risk of having it compromised.
Data is formally classified following the Information Handling Matrix (link). According to the classification, information can be either unrestricted, internal, confidential or restricted and any information that is confidential or restricted must be protected following protection guidelines.
Protection is achieved when sensitive Information that is handled by computers, normally in plain-text, human readable mode, is encrypted or transformed by scrambling it in such a way that it becomes unreadable by entities that do not possess the key to unscramble it and make it readable again. Encryption ensures confidentiality but other techniques are still needed to ensure integrity and authenticity of the information, especially when it is being transferred from one point to another.
First, by ensuring that when my data is being captured, such as when I am entering a password on an internet web form on a banking website, social network, internet mail, it is done so by a website that uses Secure Socket Layers (SSL) on the web address. In other words, the web address must use “HTTPS” at the beginning of the address instead of the legacy HTTP method that was used in the past. A second way of identifying a secure website is by looking for the padlock symbol either at the beginning of the web address. If the padlock symbol is present, it shows as locked, and the address begins with HTTPS you are using a secure website.
It is important to protect information that is set to rest, such as when it is stored on a local hard drive, a removable USB key or a backup storage unit. Protection in these cases can be achieved by using personal encryption tools such as or Bitlocker.
Data owners to reduce the risk of data compromise when at rest by:
Important! If you are a SECTIGO console user, use this console users guide for instructions.
Step 1: Request the SSL provisioning email and authentication code. If you are reading this material, you have most likely requested a certificate from IT-Security and they sent you an SSL certificate provisioning email. This email will contain two important items:
To start the request process, click on the enrollment link in your mail to open the authentication screen as shown below.
Copy and paste the code from your email into the ‘Access Code’ field. Next, Enter your email address in the space provided. This email address must be on the same domain as the certificate for which you are applying. For example, if you are applying for a certificate for www.company.com, then the email address entered here must be something like yourname@company.com. You must also be able to receive mail at this address. Next Click ‘Check access code’ to verify your application. Please contact It-Security (The SSL Administrator) if authentication fails. If authentication is successful, you should be obtaining the self-enrollment form.
Step 2: The Self-Enrollment Form: Please note that you need to fill out all fields in order to submit the form. After submitting, your application will be sent to the SSL administrator for approval and issuance. Advice on all fields on this form is available below.
Sectigo provides a range of CSR generation documents designed to assist with the CSR creation process.
The next stage of the process is to download your certificate and install it on your web-server. Once your certificate has been validated and issued you will receive a certificate collection email. The email will contain a summary of the certificate details and a link to the certificate download page. This same link will also contain a unique ID that will be used to verify the download.
After clicking on the link in the collection email, you will be able to download the certificate file.
Next, you can proceed to install the certificate. The precise installation process will depend on which type of web server you use to host your site. This page contains a list of tutorials covering certificate installation on a wide range of web servers.
This page does not intent to educate the visitor on the inner workings of SSL. If you are reading this page, it is assumed that you have some knowledge of how SSL works. The terms, Secure Socket Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably. In fact, SSL v3.1 is equivalent to TLS v1.0. However, different versions of SSL and TLS are supported by modern web browsers and by most modern web frameworks and platforms. For the purposes of this document we will refer to the technology generically as SSL/TLS.
SSL/TLS is a collection of protocols. Historically, several weaknesses have been identified with earlier SSL protocols (specifically SSLv2 and SSLv3), hence SSL versions 1, 2, and 3 should not longer be used. The best practice for transport layer protection is to only provide support for the TLS protocols – TLS 1.0, TLS 1.1 and TLS 1.2. This configuration will provide maximum protection against skilled and determined attackers and is appropriate for applications handling sensitive data or performing critical operations. Nearly all modern browsers support at least TLS 1.0. As of February 2014, contemporary browsers (Chrome v20+, Firefox v27+, IE v8+, Opera v10+, and Safari v5+) support TLS 1.1 and TLS 1.2. You should provide support for TLS 1.1 and TLS 1.2 to accommodate clients that support these protocols. The client and server (usually) negotiate the best protocol that is supported on both sides. TLS 1.0 is still widely used as the ‘best’ protocol by a lot of browsers that are not patched to the very latest version. However, TLS 1.0 suffers from CBC Chaining attacks and Padding Oracle attacks and should only be used after risk analysis and acceptance. PCI DSS 3.2 prohibits the use of TLS 1.0 after June 30, 2018 (earlier requirements to do so by June 30, 2016 were postponed). Support the extension ‘TLS_FALLBACK_SCSV’ to prevent all unnecessary fallbacks from a higher to a lower protocol version, for more details about this see RFC7507. Keep in mind that, under no circumstances either SSLv2 or SSLv3 should be enabled as a protocol selection. From the risk and security standpoint, the SSLv2 protocol is broken and does not provide adequate transport layer protection. SSLv3 had been known for weaknesses which severely compromise the channel’s security long before the ‘POODLE’ Bug finally stopped to tolerate this protocol by October 2014. Switching off SSLv3 terminates the support of legacy browsers like IE6/XP and elder (in their default configuration).
You should refrain from using wildcard certificates. Though they are expedient at circumventing annoying user prompts, they also violate the principle of least privilege and asks the user to trust all machines, including developer’s machines, the secretary’s machine in the lobby and the sign-in kiosk. Obtaining access to the private key is left as an exercise for the attacker, but its made much easier when stored on the file system unprotected. Statistics indicate wildcard certificates have a 4.4% share, so the practice is not standard for public facing hosts. Keep in mind that wildcard certificates violate EV Certificate Guidelines.
A web application visitor must never be presented with a warning that the certificate was signed by an unknown or untrusted authority. Visitors must have access to the public certificate of the certification authority which issued the server’s certificate. For Internet accessible websites, the most effective method of achieving this goal is to purchase the TLS certificate from a recognized certification authority. Popular Internet browsers already contain the public certificates of these recognized certification authorities. Utilize controls to protect the private key and ensure that only authorized individuals have the ability to sign certificates. The use of self signed certificates is never acceptable. Self signed certificates negate the benefit of end-point authentication and also significantly decrease the ability for an individual to detect a man-in-the-middle attack.
A user should never be presented with a certificate error, including prompts to reconcile domain or hostname mismatches, or expired certificates. If the application is available at both https://www.example.com and https://example.com then an appropriate certificate, or certificates, must be presented to accommodate the situation. The presence of certificate errors desensitizes users to TLS error messages and increases the possibility that an attacker could launch a convincing phishing or man-in-the-middle attack. For example, consider a web application accessible at https://abc.example.com and https://xyz.example.com. One certificate should be acquired for the host or server abc.example.com; and a second certificate for host or server xyz.example.com. In both cases, the hostname would be present in the Subject’s Common Name (CN). Alternatively, the Subject Alternate Names (SANs) can be used to provide a specific listing of multiple names where the certificate is valid. In the example above, the certificate could list the Subject’s CN as example.com, and list two SANs: abc.example.com and xyz.example.com. These certificates are sometimes referred to as “multiple domain certificates”.
RFC 1918 is Address Allocation for Private Internets. Private addresses are Internet Assigned Numbers Authority (IANA) reserved and include 192.168/16, 172.16/12, and 10/8. Certificates issued with private addresses violate EV Certificate Guidelines and should not be used.
Use fully qualified names in the DNS name field, and do not use unqualifed names (e.g., ‘localhost’), or private IP addresses (e.g., 192.168.1.1) in the DNS name field. Unqualifed names, local names, or private IP addresses violate the certificate specification.
In order to avoid presenting end users with progressive certificate warnings, organizations must proactively address the browser vendor’s push for SHA-1 deprecation. The Google Chrome plan is probably the most specific and aggressive at this point: Gradually sunsetting SHA-1. Generally speaking, all SHA-1 certificates must have expired before 1/1/2017.
When a web visitor receives a web server’s certificate, the certificate must be validated back to a trusted root certification authority. This is known as path validation. There can be one or more intermediate certificates in between the end-entity (server or host) certificate and root certificate. In addition to validating both endpoints, the web visitor’ session will also have to validate all intermediate certificates. Validating all intermediate certificates can be tricky because the visitor’s browser may not have them locally. This is a well-known PKI issue called the “Which Directory?” problem. To avoid the “Which Directory?” problem, a [well installed] server should provide the user with all required certificates used in a path validation.
A design weakness in TLS, identified as CVE-2009-3555, allows an attacker to inject a plaintext of his choice into a TLS session of a victim. In the HTTPS context the attacker might be able to inject his own HTTP requests on behalf of the victim. The issue can be mitigated either by disabling support for TLS renegotiations or by supporting only renegotiations compliant with RFC 5746. All modern browsers have been updated to comply with this RFC but your server’s SSL configuration must do its part to satisfy compliance.
Compression Ratio Info-leak Made Easy (CRIME) classified as CVE-2012-4929, is an exploit against the data compression scheme used by the TLS and SPDY protocols. The exploit allows an adversary to recover user authentication cookies from HTTPS. The recovered cookie can be subsequently used for session hijacking attacks.
The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048 bits. Additional information on key lifetimes and comparable key strengths can be found in [1], NIST SP 800-57. In addition, the private key must be stored in a location that is protected from unauthorized access.
Only use versions of crypto libraries that are supported (eg. openssl). Watch out for related SSL vulnerabilities (e.g. via cvedetails.com) and update your crypto libraries on a regular basis.
(Perfect) Forward Secrecy, abreviated as PFS, is a mechanism inherent is SSL/TLS designed to ensure the integrity of a session key in the event that a long-term key is compromised. PFS accomplishes this by enforcing the derivation of a new key for each and every session. The concept behind it is simple: client and server negotiate a key that never hits the wire, and is destroyed at the end of the SSL/TLS session. The RSA private key from the server is used to sign a Diffie-Hellman key exchange between the client and the server. The pre-master key obtained from the Diffie-Hellman handshake is then used for encryption. Since the pre-master key is specific to a connection between a client and a server, and used only for a limited amount of time, it is called Ephemeral. If an attacker gets a hold of the server’s private key, it will not be able to decrypt past communications. The private key is only used to sign the DH handshake, which does not reveal the pre-master key. Diffie-Hellman ensures that the pre-master keys never leave the client and the server, and cannot be intercepted by a MITM attack. The cipher suites that provide Perfect Forward Secrecy are those that use an ephemeral form of the Diffie-Hellman key exchange. Their disadvantage is their overhead, which can be improved by using the elliptic curve variants.
Each protocol in the TLS family (TLSv1.0, TLSv1.1, TLSv1.2, etc) contains ciphering suites . As of TLS 1.2, there is support for over 300 suites (320+ and counting), including national vanity cipher suites. The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected, the server must be modified to disable the use of weak ciphers and to configure the ciphers in an adequate order. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes. However, the challenge would be disabling weak ciphers without disabling legacy browsers and bots that have to be supported. Generally, the idea is to find the best compromise. In general, the following should be observed when enabling and selecting cipher suites:
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x33 - DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
The ordering of a ciphersuite is very important because it decides which algorithms are going to be selected in priority. The general recommendation is to prioritize algorithms that provide perfect forward secrecy. Keep in mind that older versions of OpenSSL may not return the full list of algorithms. Ciphers such as AES-GCM and some ECDHE are fairly recent, and not present on most versions of OpenSSL shipped with Debian or RHEL flavoured linuxes. The following guidelines should be used when deciding on how to prioritize the ordering of a ciphering suite:
Similarly, the following items should be mandatorily discarded:
Finally, make sure you keep yourself informed on how to securely configure and stay secure with regards to the settings for all the the products you use and which rely on some form of encryption. Resources such as BetterCrypto.org: Applied Crypto Hardening (2016) can assist in this task.
The Beast attack works by tampering with the encryption algorithms of the CBC modes and when successful, it can lead to portions of the encrypted traffic to be decrypted. To mitigate this issue, the recommendation was to disable all TLS 1.0 ciphers and only offer RC4. However, RC4 has developed a significant number of attacks against it, many of which have crossed the line from theoretical to practical. Also, there is good reason to believe that the NSA has broken RC4 via their so-called “big breakthrough”. Disabling RC4 has several ramifications. One, users with lousy browsers such as Internet Explorer on Windows XP will, in lack of the RC4, use 3DES instead. 3DES is more secure than RC4, but it is significantly more taxing for your server. Two, RC4 mitigates BEAST. Thus, disabling RC4 makes TLS 1.0 users susceptible to that attack, by moving them to AES-CBC (the usual server-side BEAST fix is to prioritize RC4 above all else). Recent browser versions have enabled client side mitigation for the beast attack. Indeed, with client-side mitigation (which Chrome and Firefox both provide), BEAST is nowadays a non-issue. But the risk from RC4 keeps growing and it will have to eventually also be abandoned.
FREAK is a man-in-the-middle (MITM) vulnerability discovered by a group of cryptographers at INRIA, Microsoft Research and IMDEA. FREAK stands for “Factoring RSA-EXPORT Keys”. The vulnerability dates back to the 1990s, when the US government banned selling crypto software overseas, unless it used export cipher suites which involved encryption keys no longer than 512-bits. It turned out that some modern TLS clients – including Apple’s SecureTransport and OpenSSL – had a bug in them. This bug causes them to accept RSA export-grade keys even when the client didn’t ask for export-grade RSA. The impact of this bug can be quite nasty: it admits a “man in the middle” attack whereby an active attacker can force down the quality of a connection, provided that the client is vulnerable and the server supports export RSA. To mitigate this, make sure your cipher-suite is updated to the latest available version and urge your clients to also use upgraded software.
Researchers from several universities and institutions conducted a study that found an issue in the TLS protocol. In the study the researchers report two attack methods. With the first attack, a man-in-the-middle can downgrade a vulnerable TLS connection to 512-bit export-grade cryptography which would allow the attacker to read and change the data. The second attack abuses the fact that many servers use the same prime numbers for Diffie-Hellman key exchange instead of generating their own unique DH parameters. Keep in mind that Diffie-Hellman key exchange allows for TLS to agree on a shared key and negotiate a secure session over a plain text connection. The researches estimated that an academic team can break 768-bit primes and that a nation-state could break a 1024-bit prime. By breaking one 1024-bit prime, one could eavesdrop on 18 percent of the top one million HTTPS domains. Breaking a second prime would open up 66 percent of VPNs and 26 percent of SSH servers. To mitigate this, make sure your SSL software is updated to the latest available version and urge your clients to also use upgraded software. To combat this, browsers now refuse DH parameters lower than 768/1024 bits. Cloudflare has a detailed guide on logjam.
OpenSSL is a widely used implementation of the Transport Layer Security (TLS) protocol and Heartbleed is a security bug affecting the OpenSSL cryptographic library and disclosed in April 2014. Heartbleed results from improper input validation (due to a missing bounds check) in the implementation of the DTLS heartbeat extension (RFC6520), thus the bug’s naming from the SSL’s “heartbeat”. Heartbleed may be exploited regardless of whether the party using a vulnerable OpenSSL instance for TLS is a server or a client. The vulnerability is classified as a buffer over-read, a situation where more data can be read than should be allowed. The bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixed the bug. If you are using an updated version of OpenSSL you are not vulnerable to this bug (see table below).
Versions of OpenSSL which are/or not affected by Heartbleed
The CRIME attack uses the SSL Compression feature to produce information leakage, and this happens when data is compressed prior to encryption. If an attacker can repeatedly inject and mix arbitrary content with some sensitive and relatively predictable data, and observe the resulting encrypted stream, then the attacker will be able to extract the unknown data from it. In practice, the attack works best against session cookies. If a man-in-the-middle (MITM) attacker 1) can observe network traffic, and 2) manipulate the victim’s browser to submit requests to the target site, the attacker can, as a result, steal the site’s cookies, and thus hijack the victim’s session. In the current form, the exploit uses JavaScript and needs 6 requests to extract one byte of data. The use of JavaScript is desired, but not required: simple tags can do the job just as well, although with a performance penalty.
To mitigate CRIME on Apache 2.2.24+, add the following line to the SSL config file:
SSLCompression off
SSLv2 has been created by Netscape in 1995 and SSLv3 by the same company in 1996. From the start, SSLv2 showed weaknesses and has quickly been replaced by SSLv3. SSLv2 was highly insecure and should no longer be enabled, one of the main reasons being that it can facilitate the DROWN attack. DROWN is a MitM (Man in the Middle) attack using principles similar to the Bleichenbacher attack (1998) and targeting SSL/TLS based protocols. DROWN allows the attacker to break the server encryption and as a result, intercept all client-server communication using the enabled SSLv2 support on the server. The attack can be successfully executed on any server that allows SSLv2, including those whose vulnerables ciphers are disabled. The successful exploitation of this vulnerability allows access to the private key, so a correctly configured server re-using a key installed on a vulnerable server would also be equally vulnerable. Openssl versions inferior to 1.0.1f and 1.0.2g are especially vulnerable due to a bug allowing the use of disabled vulnerable ciphers, facilitating the exploitation of the vulnerability in minutes using consumer-grade hardware. For most late generation browsers, a yellow triangle appears on the padlock when the website visited uses an outdated protocol such as SSLv2 or SSLv3. To disable these on the server side, insert this line on the Apache SSL config file:
SSLProtocol All -SSLv2 -SSLv3
All is a shortcut for +SSLv2 +SSLv3 +TLSv1 or – when using OpenSSL 1.0.1 and later – +SSLv2 +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2, respectively. The above line enables everything except SSLv2 and SSLv3. More info on the apache website
For Openssl users, a migration toward versions equal or superior to 1.0.1f or 1.0.2g is strongly advised.
Despite being quite old, SSLv3 was still being kept enabled in SSL/TLS implementations dating back to 2014 and prior, mostly with the intent of remaining backwards compatible. This was achieved by allowing for protocol downgrading for legacy clients – an operation known as SSLv3 FallBack. The POODLE attack (Padding Oracle On Downgraded Legacy) shattered this by producing an attack that relies on the non-deterministic feature of the cipher block padding of CBC encryption, and which integrity cannot be verified during decryption. PODDLE subverts this padding and by means of this, reveal significant parts of the encrypted message if applied continuously. The recommendation for mitigation is to disable SSLv3 altogether. If there is occasional need to work with legacy systems, the TLS-FALLBACK-SCSV mechanism can be used to prevent an attacker from forcing a protocol downgrade. This extension was originally proposed by Google to prevent forced SSL protocol downgrade.
This attack is aptly named after a 19-year-old vulnerability that allows performing RSA decryption and signing operations with the private key of a TLS server. In 1998, Daniel Bleichenbacher discovered that the error messages given by SSL servers for errors in the PKCS #1 v1.5 padding allowed an adaptive-chosen ciphertext attack; this attack fully breaks the confidentiality of TLS when used with RSA encryption. For hosts that are vulnerable and only support RSA encryption key exchanges it’s pretty bad. It means an attacker can passively record traffic and later decrypt it. For hosts that usually use forward secrecy, but still support a vulnerable RSA encryption key exchange the risk depends on how fast an attacker is able to perform the attack. ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. The RSA encryption modes are so risky that the only safe course of action to mitigate this is to disable them (the ciphers that start with TLS_RSA). Apart from being risky these modes also lack forward secrecy. Ciphers that do use RSA signatures, namely the ones that include DHE and ECDHE in their name are not affected by ROBOT. Preliminary tests have determned that the cost of disabling RSA encryption modes are relatively low. Cloudflare indicates that around one percent of their connections use the RSA encryption modes and disabling these modes on HTTPS servers operated by them caused no notable problems.
Adapted from: OWASP: Transport Layer Security Cheat Sheet Strong SSL Security on Apache2 OPENSSL Vulnerabilities
Issues with SSL Certificates (Intermediate/Root)
In order to generate a Certificate Signing Request (CSR) you must have a private key ready to be used for the CSR generation. This key should be at least a 2048 bit RSA key and must be encrypted using either Triple-DES or any other applicable method and must be stored in a PEM format so that it is readable as ASCII text.
Generating a private RSA key
openssl> genrsa -des3 -out server.key 2048
The above command will ask to enter a passphrase to protect this key in case it gets stolen or compromised. The passphrase should be strong enough to prevent tampering. If successful, this command will generate a file in the format “server.pem” where “server” is the name you assigned in the command. This obviously can be any other name if so you choose.
Generating a CSR (Certificate Signing Request)
Once the private key is ready, a Certificate Signing Request (CSR) can be generated. This CSR can then be sent to a Certificate Authority, such as Thawte, Verisign or in our case SECTIGO to verify the identity of the requester and issue a signed certificate. During the generation of the CSR, you will be prompted for several pieces of information such as country, state, organization, etc. These pieces will become the X.509 attributes of the certificate. The only critical piece is the common name, which needs to be set to the FQDN of the server that is going to be protected by SSL. If the website to be protected is for example https://www.mcmaster.ca, then enter “www.mcmaster.ca” at this prompt. Use this openssl command to generate the CSR as follows:
openssl> req -new -key server.key -out server.csr
Country Name (2 letter code) [CA]:CA State or Province Name (full name) [Ontario]:Ontario Locality Name (eg, city) [Hamilton]: Hamilton Organization Name (eg, company) [My Company Ltd]: McMaster University Organizational Unit Name (eg, section) []: Media Production Services Common Name (eg, your name or your server’s hostname) []: mps.mcmaster.ca Email Address []: your-name@mcmaster.ca Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []: An optional company name []:
If a challenge password was issued (not left blank) this might need to be entered when the CSR is uploaded to the console.
Once the CSR generation is complete you will obtain a file named “server.csr” with the private key for this request in the file “server.pem”. It is recommended that this key is made valid for this CSR only. You should not use this key on multiple CSRs for security reasons.
Uploading the CSR to start the certificate request process
Once you have the CSR ready, go to the SECTIGO console and select “add” to enter a new request for a certificate. You will presented with a screen offering 3 modes of CSR upload:
Select “Manual creation of CSR” and hit the “Next” button.
In the next step you will be prompted to either copy and paste the content of your CSR file or upload the CSR file on to the field by pressing the “Upload CSR” button.
After the CSR is uploaded, you will be presented with a number of custom fields required to classify and store the certificate once generated. make the appropriate choices as follows:
If you want to add extra common names to the certificate request, you must select the “EV Multidomain SSL” type. This option will give you the choice of adding extra common names if applicable. Otherwise, the type should remain as “Elite SSL Certificate”.
When you are done, hit the “Next” button.
The next screen will show the “auto-renewal” options. Check off the auto renewal box if you want this certificate to be automatically renewed at the expiration date. Also, select the number of days prior to expiry that can be used to calculate the exact time of renewal for the certificate.
When you are ready, hit the “Next” button.
Finally, accept the EULA terms and conditions to complete the request process. This will put the certificate in the queue awaiting for approval.
Certificate Deployment
After the certificate is approved and issued, you will receive an email indicating that the SSL certificate is ready to be collected. The email should contain links to retrieve the certificate in the format that is applicable to your server. Once you retrieve the certificate file, you will need to upload it on to your web server along with the private key that was used to generate it.
Please note that the private key that is going to be uploaded to the server must be devoid of the protection password that was initially used to generate the key and obtain the CSR. This is an important point, as uploading the private key with the protection passphrase in place, will prompt the web server to enter that passphrase every time the certificate must be loaded for use.
To remove the password from the private key file prior to uploading it to the server, use the following OpenSSL command:
openssl> rsa -in [file1.key] -out [file2.key]
After the command is entered, you will be prompted for the passphrase that was used to generate [file1.key]. Once the command is completed you will get [file2.key] which is now the unprotected private key. This file is the one that should be uploaded to the server along with the corresponding, new SSL certificate.
Be aware that having an unencrypted private key adds a security risk by making it easier to compromise your SSL encryption scheme if your unprotected private key file is stolen. Once uploaded to the server, any other copies of the key must not be left lying around and security measures must be taken to protect the original key file storing it in a safe place, ideally on a key vault system or service.
Once the SSL certificate is in place along with the key, you can then proceed to reference to it from your server environment for it to become active.
SSL certificates are issued by companies referred to as “certificate authorities”. Our SSL Certificate Provider, SECTIGO (previously known as COMODO) is one such company. As a result of their recent change of company names, SECTIGO issued a new set of intermediate certificates to ensure 100% trust when using their certificates. This has caused some confusion in some cases, due to certificates that have been installed without the provided complete suite of certificates on to their servers. This in turn caused some trust issues as some browsers, Firefox in particular, failed to recognize the newly deployed certificate as trustworthy due to “intermediate certificate” issues.
Every time a browser encounters an SSL certificate, it checks its own list of Trusted Root Certificates in order to establish a secure connection. These lists are generally the same across different browsers, but sometimes, discrepancies can occur. A typical issue arises when for example one browser lists a Trusted Root certificate or intermediate certificate while another browser might not. Additionally, browsers do not handle certificates in the same way. In this brief article we try to explain how issues might arise and how to address them.
Typically, certificates vary from what are known as single root certificates, usually expensive, to less costly certificates known as “chained root certificates”. Our attention will focus on the latter kind. Chained root certificates normally consist of an end-user certificate and one or more intermediate certificates that point to a root certificate. From the browser’s perspective, an SSL Certificate will only be recognized as trustworthy if the root certificate the end-user certificate refers to in order to establish “trust” is listed in the “Trusted Root Certificates” of the browser. If that chain of trust cannot be established or completed, the visitor will see a warning message and may be unable to establish a secure connection to the site.
The key factor to keep in mind when dealing with “chained” certificates is hierarchy. Certificates that are chained obey a hierarchy that has been established to resolve and discover the ultimate source of trust: the root certificate. If the root certificate is not discovered, the end-user certificate is untrustworthy. Separate from that, intermediate certificates by themselves are useless unless they are positioned in such a way that they can be used to discover and resolve the chain of trust.
The diagram below shows how the chain tipically looks in a Windows system:
A number of factors can come into play when browsers are attempting to resolve the chain and establish trust:
If any of the above items are off or not properly aligned, the user experience might be affected.
To counter for this potential problem, resulting primarily from the recent name change, Sectigo issued the following new set of intermediate certificates in December 2018:
Subject: CN=Sectigo RSA Organization Validation Secure Server CA; Serial Number: 137d539caa7c31a9a433701968847a8d; expiry Date: ?Tuesday, ?December ?31, ?2030 6:59:59 PM; Thumbprint: 40cef3046c916ed7ae557f60e76842828b51de53
Subject: CN=USERTrust RSA Certification Authority; Serial Number: 13ea28705bf4eced0c36630980614336; Expiry Date: ?Saturday, ?May ?30, ?2020 5:48:38 AM; Thumbprint: eab040689a0d805b5d6fd654fc168cff00b78be3
Compare the above with the old set of intermediate certificates previously released by Comodo:
Subject: CN=COMODO RSA Organization Validation Secure Server CA; Serial Number: 36825e7fb5a481937ef6d1736bb93ca6; Expiry Date: ?Sunday, ?February ?11, ?2029 6:59:59 PM; Thumbprint: 104c63d2546b8021dd105e9fba5a8d78169f6b32
Subject: CN=COMODO RSA Certification Authority; Serial Number: 2766ee56eb49f38eabd770a2fc84de22; Expiry Date: ?Saturday, ?May ?30, ?2020 5:48:38 AM; Thumbprint: f5ad0bcc1ad56cd150725b1c866c30ad92ef21b0
Both the old and the new set still point to the following root certificate as shown in the diagram below:
Subject: CN=AddTrust External CA Root; Serial Number: 1; Expiry Date: ?Saturday, ?May ?30, ?2020 5:48:38 AM; Thumbprint: 02faf3e291435468607857694df5e45b68851868
Comparing both sets show that they have different primary and secondary intermediate, but the same root certificate. The new set now shows the company name as SECTIGO. As OS and browsers get updated, they should receive the new sets of intermediate certificates but until that happens, the resolving of the chain and discovery of the root must be accomplished by having the web server to provide both the end-user certificate and the intermediate certificates. The root certificate is much older and it exists on 99% of all local OS and browser SSL repositories. Systems receive updates in a flexible manner depending on the service providing these updates and the owner of the system’s diligence in staying updated. Some systems will not get updated for various reasons (i.e., users neglecting to update or unable to reach a source of updates). Issues resulting from these scenarios should be treated on a case by case basis and will depend on the condition of the client system at the time the issue is occurring.
Notice also that, on the new set, the expiry dates of the intermediates and root are sometime in the year 2020. This will require that Sectigo issue new intermediate certificates for all browsers globally sometime in the near future or resort to some other mechanism to resolve trust most likely using another intermediate certificate that can also be found on 99% of systems:
Subject: CN=COMODO RSA Certification Authority; Serial Number: 4caaf9cadb636fe01ff74ed85b03869d; Expiry Date: ?Monday, ?January ?18, ?2038 6:59:59 PM; Thumbprint: afe5d244a8d1194230ff479fe2f897bbcd7a8cb4
This certificate has the same purpose as the old intermediate that was previously distributed by Comodo but with a much later expiration date and could still be used to resolve chains in future deployments.
It has been observed that when client systems experience SSL trust problems, particularly when opening browsing sessions, the system might keep and use a cache of visited pages despite the SSL issue having been resolved on the server side, giving the impression after re-visiting the web site that there is still a problem when in fact the issue has been resolved. To ensure this does not happen, we recommend asking clients to browse using the “New Private Window” option. This method will ensure that no old cache, cookies or pre-existing settings are used when visiting a web site. If the SSL issue has indeed been resolved on the server side, this method of browsing will make sure that a fresh session is started and will show the updated status of the SSL certificate.
Sectigo SSL certificates rely on a chain to establish trust and discover the root Certificate Authority. In order to prevent issues stemming from browsers having different levels and versions of the intermediate certificates in their local repositories, servers using SSL certificates must contain and provide the proper intermediate certificates to assist client browsers in trying to establish trust by properly resolving the SSL chain. Intermediate certificates are deployed in the same manner as regular end-user certificates and the method depends on the type of web server technology. When requesting SSL certificates, administrators must carefully specify the type of certificate and the web server technology it will be deployed on. following the tips provided above will ensure that Sectigo provides the proper set of certificates for the indicated type of server.
Keep in mind that you can secure your website using SSL encryption at no cost to you or your department. McMaster University is now offering SSL, Code signing and client certificates from Sectigo to users at no charge. You can request an SSL certificate by contacting the IT Security team at c-it-security@mcmaster.ca or by submitting a UTS help desk ticket. As well, IT administrators who are interested in managing their group’s certificates can request to be added to the Sectigo administrator console by getting in touch with the IT Security team.
You can read more on the process of obtaining an SSL certificate by visiting Comodo SSL Certificates
Adapted from: SSL certificates, intermediate certificates and browser compatibility Understanding An SSL Certificate Chain