How to Obtain SSL/TLS certificates from the UTS Certificate Management System

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:

• A link to the certificate enrollment/renewal web page. The URL will be similar to https://cert-manager.com/customer//ssl
• An access code which will be used to authenticate you before you can proceed to the enrollment form.

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.

Form Notes and Advice

• The ‘Access Code’ and ‘E-mail’ address fields will be pre-populated as you entered them previously.
• The EV application form contains additional fields related to Incorporating Agency and certificate requester, approver and signer. The MDC form contains an additional SAN field so you can add multiple domain names.
• In addition to the standard fields in the enrollment form, additional custom fields such as ‘Telephone No.’ ‘Employee Code’ may also be displayed depending on how the administrator has configured it.

Sectigo provides a range of CSR generation documents designed to assist with the CSR creation process.

• After you have successfully submitted the form, your application will go for approval by your SSL administrator. Once approved, your certificate request will be forwarded to Sectigo CA for issuance and you will be notified by email when it is ready for collection.

Certificate Collection and Installation

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.

How to Set Up Strong SSL Security on Servers that Require Encryption

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.

Only Support Strong Protocols

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).

Do Not Use Wildcard Certificates

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.

Use an Appropriate CA

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.

Use a Certificate That Supports Required Domain Names

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”.

Do Not Use RFC 1918 Addresses (Private Addresses) in 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 Certificates

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.

Be aware of the SHA-1 deprecation

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.

Always Install/Provide All Needed Certificates

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.

Only Support Secure Renegotiations

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.

Disable Compression

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.

Use Strong Keys & Protect Them

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.

Update your Crypto Libraries

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.

Use Forward Secrecy

(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.

Only Support Strong Cryptographic Ciphers

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:

• Set your settings so that the cipher order is activated by the server, e.g. ‘SSLHonorCipherOrder On’
• Disable cipher suites that do not offer encryption (eNULL, NULL)
• Disable cipher suites that do not offer authentication – specifically aNULL (aNULL includes anonymous cipher suites ADH [Anonymous Diffie-Hellman] and AECDH [Anonymous Elliptic Curve Diffie Hellman]).
• Prefer ciphers that support ‘Forward Secrecy’
• Keep in mind that it is not recommended to use 3DES together with perfect forward secrecy ciphers (DHE, ECDHE). To be safe, disable 3DES completely.
• Priorize the ciphers by the sizes of the cipher and the MAC
• Use SHA1 or above for digests, prefer SHA2 (or equivalent)
• Disable export level ciphers (EXP, eg. ciphers containing DES)
• Disable key sizes smaller than 128 bits for encrypting payload traffic
• Disable the use of MD5 as a hashing mechanism for payload traffic
• Disable the use of IDEA cipher suites
• Disable RC4 cipher suites
• Favor GCM over CBC regardless of the cipher size. Be aware that CBC suites are all deprecated now.
• If you want to get very granular, define a cipher string that works with different versions of your encryption tool, like openssl
• Verify your cipher string with an audit-tool or manually as shown below – there are many ssl test/audit tools out there (check with the IT Security team)

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

PFS and Cipher Prioritization Logic

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:

• ECDHE+AESGCM ciphers should be selected first. These are TLS 1.2 ciphers. No known attack currently target these ciphers.
• PFS ciphersuites should be preferred, with ECDHE first, then DHE.
• AES 128 should preferred to AES 256. There has been discussions on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks.
• If you are using a backwards compatible ciphersuite, AES should be preferred to 3DES. BEAST attacks on AES are mitigated in TLS 1.1 and above, and difficult to achieve in TLS 1.0. In the non-backward compatible ciphersuite, 3DES is not present.
• RC4 must be removed entirely. 3DES is used for backward compatibility.

Similarly, the following items should be mandatorily discarded:

• aNULL contains non-authenticated Diffie-Hellman key exchanges, that are subject to Man-In-The-Middle (MITM) attacks
• eNULL contains null-encryption ciphers (cleartext)
• EXPORT are legacy weak ciphers that were marked as exportable by US law
• RC4 contains ciphers that use the deprecated ARCFOUR algorithm
• DES contains ciphers that use the deprecated Data Encryption Standard
• SSLv2 contains all ciphers that were defined in the old version of the SSL standard, now deprecated
• MD5 contains all the ciphers that use the deprecated message digest 5 as the hashing algorithm

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.

Most Common SSL/TLS Attacks and Mitigations

BEAST and RC4

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 (Factoring RSA-EXPORT Keys)

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.

Logjam (DH EXPORT)

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.

Heartbleed

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

• OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
• OpenSSL 1.0.1g is NOT vulnerable
• OpenSSL 1.0.0 branch is NOT vulnerable
• OpenSSL 0.9.8 branch is NOT vulnerable

CRIME (SSL Compression attack)

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 and DROWN

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.

SSLv3 and POODLE

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.

Return Of Bleichenbacher’s Oracle Threat (ROBOT)

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

Other Articles:

Issues with SSL Certificates (Intermediate/Root)

Certificate Signing and Requesting Process

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:

• Manual creation of CSR
• Auto-generation of CSR
• Auto-generation of CSR with auto installation

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:

• Make sure “McMaster University” is selected as the Organization
• Select your Department from the pull down list, whatever is appropriate
• Select Certificate Type as “Elite SSL Certificate” or “EV Multidomain SSL” ( the difference is explained below)
• Select the validity Term (1 or 2 years)
• Double check the common name and ensure it matches what you have indicated during the CSR generation process
• Select “Server Software”. This step is very important as the format for the issued certificate will match the appropriate selection. The selection must match or at least closely resemble the platform the certificate is going to be deployed to.
• The “Requester” field should show your name
• the “External Requester” field is to add names other than yourself that are also part of this request. This is optional

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.

Resolving Problems With Intermediate Certificates

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:

• the type of browser
• the operating system and browser version level and its local SSL repository status
• the server’s SSL certificate deployment scenario
• the age of the end-user and intermediate certificates

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:

New primary intermediate:

Subject: CN=Sectigo RSA Organization Validation Secure Server CA;
Serial Number: 137d539caa7c31a9a433701968847a8d;
expiry Date: ?Tuesday, ?December ?31, ?2030 6:59:59 PM;
Thumbprint: 40cef3046c916ed7ae557f60e76842828b51de53

New secondary intermediate:

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:

Old primary intermediate:

Subject: CN=COMODO RSA Organization Validation Secure Server CA;
Serial Number: 36825e7fb5a481937ef6d1736bb93ca6;
Expiry Date: ?Sunday, ?February ?11, ?2029 6:59:59 PM;
Thumbprint: 104c63d2546b8021dd105e9fba5a8d78169f6b32

Old secondary intermediate:

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:

Root certificate:

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.

Caching problems

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.

In Summary

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