Self-signed certificates are widely used in testing environments and they are excellent alternatives to purchasing and renewing yearly certifications.
That is of course if you know how and, more importantly, when to use them. Remember, that A self-signed certificate is not signed by a publicly trusted Certificate Authority (CA). Self-signed certificates are considered different from traditional CA certificates that are signed and issued by a CA because self-signed certificates are created, issued, and signed by the company or developer who is responsible for the website or software associated with the certificate.
You are probably reading this article because for some reason, you need to create a self-signed certificate with Windows. So, we’ve tried to outline the easiest ways to do that. This article is up-to-date as of December 2021. By the way, we’re referring to Windows 10 for all the following tutorials. As far as we know, the processes for Windows 11 are identical.
These guys offer free CA certificates with various SAN and wildcard support. The certificate is only good for 90 days, but they do give an automated renewal method. This is a great alternative for a quick proof-of-concept. Other options would require more typing, for sure.
But this option works only if you want to generate a certificate for your website. The best way to start is by going to Getting Started, the instructions thereafter are very easy to follow.
Other one-click option:
We’ve reviewed different online services that allow you to easily generate self-signed certificates. We’ve sorted them from one-click to advanced, and the first one is:
Among the online services that allow you to generate self-signed certificates, this one is the most advanced; just look at all available options to choose from:
Now let’s continue with offline solutions, that are a bit more advanced:
PowerShell 4.0
1. Press the Windows key, type Powershell. Right-click on PowerShell and select Run as Administrator.
2. Run the New-SelfsignedCertificate command, as shown below.
7. In the above command, replace c:temp with the directory where you want to export the file.
8. Import the exported file and deploy it for your project.
Use OpenSSL
1. Download the latest OpenSSL windows installer from a third-party source;
2. Run the installer. OpenSSL requires Microsoft Visual C++ to run. The installer will prompt you to install Visual C++ if it is already not installed;
3. Click Yes to install;
4. Run the OpenSSL installer again and select the installation directory;
5. Click Next;
6. Open Command Prompt and type OpenSSL to get an OpenSSL prompt.
The next step would be to generate a public/private key file pair.
1. Open Command Prompt and create a new directory on your C drive:
C: >cd Test
2. Now go to the new directory:
C: Test>
3. Now you need to type the path of the OpenSSL install directory followed by the RSA key algorithm:
4. You need to enter information about your organization, region, and contact details to create a self-signed certificate.
We also have a detailed article on OpenSSL – it contains more in-depth instructions on generating self-signed certificates.
Using IIS
This is one of those hidden features that very few people know about.
1. From the top-level in IIS Manager, select “Server Certificates”;
2. Then click the “Create” button on the right;
3. This will create a self-signed certificate, valid for a year with a private key. It will only work for “localhost”.
We hope this fruit bowl of options provides you with some choice in the matter. Creating your own self-signed certificate nowadays is trivial, but only until you begin to understand how they really work.
Our option of choice is, of course, OpenSSL — after all, it is an industry-standard.
7 ways to create self-signed certificates on Windows
1.1 What Are ‘Certificates’ and Why Are They Needed?
Certificates are text files on a web server, the placement and content of which confirms the identity of the responsible owner of a web resource. Owner confirmation is carried out by specially authorized companies or divisions of an organization – Certification Centers (also referred to as the CC, Certificate Authority, CA).
Additionally, certificates contain the public key required to establish an encrypted connection to work on a network in order to prevent data interception by intruders. The protocols by which this connection is established end with the letter "S", from the English word "Secure" — see HTTP(S), FTP(S), etc. This means that standard internet protocols, such as HTTP and FTP, are used over an encrypted TLS connection, whereas ordinary messages are exchanged over TCP/IP without encryption. TLS (which stands for Transport Layer Security is a protocol that ensures secure data transfer based on SSL (Secure Sockets Layer), which is another cryptographic protocol. This uses asymmetric cryptography to authenticate exchange keys so that a session can be established, symmetric encryption to further preserve the confidentiality of the session, and the cryptographic signature of messages to guarantee the delivery of information without loss. Despite the fact that it is the only TLS protocol that is actually used, due to habit, the entire family of these protocols is called SSL, and the accompanying certificates are SSL certificates.
The use of SSL certificates primarily allows you to prevent data theft by using clones of sites of well-known services, when attackers duplicate the main pages of said sites, employ similar domain names, and forge personal information forms. The user may input personal information about themselves, their documents, and payment details on fake websites. As a result, users' personal information may subsequently be used to gain unauthorized access to other resources or social networks so it can be resold, or used to steal funds from a bank account. Service owners can help customers avoid these problems by configuring HTTPS on their resource and demonstrating the authenticity of their web pages to their users directly in the browser address bar.
As mentioned above, TLS/SSL is used to encrypt traffic from the client to the web server, and this prevents intruders from intercepting traffic on public unsecured networks.
1.2 How Do They Work?
When it comes to TLS /SSL, three parties are involved: the client – the consumer of services or goods on the internet; the server – the provider of these services or goods; and the Certification Center, whose duties include ensuring that the domain name and resource belong to the organization specified in the registration information of the certificate.
The TLS/SSL algorithm works as follows:
1. The owners of the service contact the Certification Center through partners and provide information about themselves.
2. The Certification Center makes inquiries about the owners of the service. If the primary information is verified, the Certification Center issues the owners of the service with a certificate which includes the verified information and a public key.
3. The user launches a browser on a personal device and goes to the service page.
4. The browser, along with other standard operations, requests the SSL certificate while the service page is loading.
5. The service sends the browser a copy of the certificate in response.
6. The browser checks the validity period and validity of the copy of the certificate using the Certificate Centers’ pre-installed root certificates. If everything is approved, the browser sends the corresponding response to the service, signed with the client's key.
7. The service receives confirmation of the client’s verification with their digital signature and they begin an encrypted session.
Session encryption is carried out using PKI (Public Key Infrastructure). PKI is based on the following principles:
1. There is a related pair of non-interchangeable control sequences of almost random characters called keys: public or public and private, also referred to as private.
2. Any dataset can be encrypted with a public key. Because of this, the public key can be freely transmitted over the network, and an attacker will not be able to use it to harm users.
3. The private key is known only to its owner and can decrypt the received data stream into structured information that has been encrypted with a public key paired with it. The private key should be stored on the service and used only for local decryption of messages that have been received. If an attacker is able to gain access to a private key, then procedures for revoking and reissuing the certificate must be initiated to make the previous certificate useless. A leak of a private key is called a compromise.
An SSL certificate from a Certificate Authority is one way of distributing a server’s public key to clients in unsecured networks. After verifying the validity of the certificate, the client encrypts all outgoing messages with the public key attached to the certificate and decrypts incoming messages with the private one, thereby ensuring a secure communication channel.
1.3 Who Releases Them?
Certificates are issued by Certification Centers upon the request of customers. The Certification Center is an independent third–party organization that officially verifies the information specified in a certificate request: i.e. whether the domain name is valid, whether a network resource with this name belongs to a specific company or individual to whom it is registered; whether the site of the company or individual to whom the SSL certificate was issued is genuine, and other checks. The most famous international Certification Centers are Comodo, Geotrust, GoDaddy, GlobalSign, Symantec. The root SSL certificates of these Certification Authorities are pre-installed as trusted in all popular browsers and operating systems.
It is often more cost-effective to purchase certificates not directly from the Certification Center but from their partners instead, as they offer wholesale discounts. In Russia, many companies and hosting providers that have their own tariffs for the SSL certificate service sell certificates from well-known Certification Centers.
2. Advanced Information about Certificates
2.1 Which Crypto Algorithms Are Used?
The following algorithms are used to establish a secure connection:
Encryption algorithm
Hashing algorithms
Authentication algorithms
The most commonly used encryption algorithms for cryptographic operations in TLS/SSL are combinations of the algorithms RSA (an initialism of the names of the creators Rivest, Shamir and Adleman), DSA (which stands for Digital Signature Algorithm, patented by the National Institute of Standards and Technology of the USA) and several variations of the Diffie–Hellman algorithm or DH, such as a one-time DH (Ephemeral Diffie–Hellman, EDH) and DH based on elliptic curves (Elliptic curve Diffie–Hellman, ECDH). These Diffie-Hellman variations, unlike the original algorithm, provide progressive secrecy, i.e. when previously recorded data cannot be decrypted after a certain amount of time — even if it was possible to obtain the server's secret key — because the original parameters of the algorithm are generated again when the channel is re-established after a forced break when the connection has timed out.
Hashing algorithms are based on a family of mathematical functions for calculating the hash SHA (Secure Hash Algorithm). The hash function allows you to convert the original data array into a string of a certain length, and this length determines the amount of processing time and the computing power required. All encryption algorithms today support the SHA2 hashing algorithm, most often SHA-256. SHA-512 has a similar structure, but in it the word length is 64 bits rather than 32, the number of rounds in the cycle is 80 rather than 64, and the message is divided into blocks of 1024 bits rather than 512 bits. Previously, SHA1 and MD5 algorithms were used for the same purpose, but today they are considered vulnerable to attack. Modern services use keys 64 bits long and higher. The current version of the SHA-3 algorithm (Keccak), uses an amount necessary to verify the integrity of the transmitted data — MAC (Message Authentication Code). The MAC uses the mapping function to represent message data as a fixed length value, and then hashes the message.
In modern versions of the TLS protocol, HMAC is used (Hashed Message Authentication Code), which uses a hash function immediately with a shared secret key. This key is transmitted along with the flow of information, and to confirm authenticity, both parties must use the same secret keys. This provides greater security.
The General Algorithm of SSL Operation
1. Handshake protocol. The connection confirmation (handshake) protocol is the order of operations performed directly during the initialization of the SSL connection between the client and the server. The protocol allows the server and client to carry out mutual authentication, determine the encryption algorithm and MAC, as well as secret keys to protect data during a further SSL session. The handshake protocol is used by participants at the stage before data exchange. Each message transmitted as part of the handshake protocol contains the following fields:
Type is the category of messages. There are 10 categories of messages.
Length refers to the length of each message in bytes.
The content is the message itself and its parameters.
During the handshake, the following stages take place:
1.1 Determination of supported algorithms. At the first stage, the connection between the client and the server is initiated and the encryption algorithms are selected. First, the client sends a welcome message to the server, before entering response-waiting mode. After receiving the client's welcome message, the server returns its own welcome message to the client to confirm the connection. The client's welcome message includes the following data:
The maximum SSL version number that the client can support
A 32-byte random number used to generate the master secret
Session ID
A list of cipher suites
A list of compression algorithms
The format of the list of cipher suites is as follows:
<1>_<2>_<3>_<4>
Wherein lies:
The name of the protocol, for example, "SSL" or "TLS".
Key exchange algorithm (with an indication of the authentication algorithm).
The encryption algorithm.
Hashing algorithm. For example, the entry "SSL_DHE_RSA_WITH_DES_CBC_SHA" means that the fragment "DHE_RSA" (temporary Diffie-Hellman with RSA digital signature) is defined as a key exchange algorithm; the fragment "DES_CBC" is defined as an encryption algorithm; and the fragment "SHA" is defined as a hashing algorithm. As will be discussed later in TLSv1.3, the key exchange and encryption protocols are combined into an authenticated encryption algorithm with attached data (AEAD), so the entry there will be shorter. Example: TLS_AES_256_GCM_SHA384. The server response includes the following fields:
The SSL version number. On the client side, the lowest version number supported by the client and the largest version number supported by the server are compared. Depending on the server’s settings, selection priority can be given to either the client or server.
A 32-byte random number used to generate the master secret.
Session ID.
A set of ciphers from the list of ciphers supported by the client.
Compression method from the list of compression methods supported by the client.
1.2 Server authentication and key exchange
At the second stage, all messages are sent by the server. This stage is divided into 4 steps:
The sending of a digital certificate to the client so they can use the server's public key for authentication purposes.
Key exchange on the server. Depending on the established algorithm, this step may be skipped.
Client certificate request. Depending on the settings, the server may require the client to send their own certificate.
A message confirming that the server authentication and key exchange stage is complete, before moving on to the next stage.
1.3 Client authentication and key exchange:
At the third stage, all messages are sent by the client. This stage is divided into 3 steps:
The sending of the certificate to the server — if the server requested it (this depends on the established algorithm). If the algorithm includes this, the client can authenticate on the server. For example, in IIS, you can configure mandatory authentication of the client certificate.
Client key exchange (Pre-master-secret) – the sending of the master key to the server, which will later be encrypted using the server key. The client knows the master key and in case of server substitution will be able to terminate the connection.
Signing a random number to confirm ownership of the certificate's public key. This stage also depends on the algorithm chosen.
1.4 Server shutdown
At the fourth stage, messages are exchanged directly and errors are monitored. If an error is detected, the alarm protocol comes into effect. This stage consists of exchanging session messages: the first two messages come from the client, and the last two come from the server.
2. The Key Generation Process
To ensure the integrity and confidentiality of information, SSL requires six encryption secrets: four keys and two values of the initialization vector (IV, see below). The information’s authenticity is guaranteed by an authentication key (for example, HMAC). The data is then encrypted by a public key, and data blocks are created based on IV. The keys required by SSL are unidirectional, so when a client is hacked, the data obtained cannot be used to hack the server.
3. Record Agreement (Record Protocol)
The recording protocol is used after a connection between the client and the server has been successfully established, and when the client and server have passed mutual authentication and have determined the algorithm they will use to exchange information about the algorithms used. The recording protocol implements the following functions:
Confidentiality by using the secret key defined at the handshake stage;
Integrity by analyzing the MAC defined at the handshake.
4. Alarm Protocol
When the client and server detect an error, they send a message recognizing this. If it is a critical error, the algorithm immediately closes the SSL connection, and both sides first delete the session details: the identifier, secret, and key. Each error message is 2 bytes long. The first byte indicates the type of error. If the connection fails, the value is 1, while if a critical error is detected, it is 2. The second byte indicates the nature of the error.
2.2 Versions of SSL (SSL, TLS) — and How They Differ
During the initial installation of a secure connection between the client and the server, the protocol is selected from those supported by both sides from the set of SSLv3, TLSv1, TLSv1.1, TLSv1.2 or TLSv1.3.
Earlier versions of the SSL protocol are not used. The SSLv1 version was never made public. The SSLv2 version was released in February 1995, but it contained many security flaws that led to the development of SSLv3. Various IT companies have begun to attempt to implement their own versions of secure data transfer protocols. In order to prevent disunity and monopolization in the field of network security, the international community of designers, scientists, network operators, and providers (The Internet Engineering Task Force [IETF]), which was created by the Internet Architecture Council in 1986, is involved with developing protocols and organizing the internet, specifically regarding the standardized TLS protocol version 1, slightly different from SSL 3.0.
The technical details of the protocol are recorded by the release of a document called RFC (Request for Comments, working proposal). These documents can be found on the IETF website: www.ietf.org/rfc/rfcXXXX.txt , where XXXX is a four-digit RFC number. Thus, the TLSv1 version is fixed in RFC 2246, the TLSv1.1 version is fixed in RFC 4346, the TLSv1 version.2 in RFC 5246, and the TLSv1 version.3 in RFC 8446. In addition, RFC 3546 defines several extensions for cases when TLS is used in systems with limited bandwidth, such as wireless networks; RFC 6066 defines a number of additional TLS changes made to the extended client greeting format (presented in TLSv1.2); RFC 6961 defines a method for reducing traffic when a client requests information about the status of a certificate from the server; and, finally, RFC 7925 defines what happens to TLS (and DTLS) when it is used in IoT (Internet Of Things) to exchange data between hardware and other physical objects without human intervention.
As mentioned above, the TLSv1 protocol was released as an update to SSLv3. RFC 2246 states that "the differences between this protocol and SSLv3 are not hugely significant, but they are significant enough to exclude interaction between TLSv1 and SSLv3."
In contrast to the TLS Version 1.0, the TLSv1.1 protocol provides:
Added protection against attacks using CBC (Cipher Block Chaining), when each block of plaintext is associated with the previous block of ciphertext before encryption. 1. The implicit initialization vector (the original pseudorandom number initiating the calculation of the further cipher, IV) was replaced by an explicit one which is not secret, but nonetheless cannot be predicted in a reasonable timeframe. 2. A change in the handling of block filling errors when a data packet is expanded to a fixed block size.
Support for registering server IP address parameters and other network information.
The TLS 1.2 protocol is based on the TLS 1.1 specification. This is the most common at the moment. The main differences include:
The combination of MD5–SHA-1 hashing algorithms in a pseudorandom function (PRF) has been replaced by the more secure SHA-256, with the possibility of using a set of ciphers, the specified function.
The hash size in the finished message has become at least 96 bits.
The combination of MD5–SHA-1 hashing algorithms in the digital signature has been replaced by a single hash agreed upon during the handshake, which is SHA-1 by default.
The implementation of the function of selecting encryption and hashing algorithms for the client and server.
The extension of support for authenticated encryption ciphers used mainly for Galois/Counter mode (GCM) and CCM mode for Advanced Encryption Standard (AES).
The addition of TLS extension definitions and AES cipher suites.
The ending of backward compatibility with SSLv2 as part of the 6176 RFC. Thus, TLS sessions have ceased to negotiate the use of SSL version 2.0.
The TLS 1.3 protocol is based on the TLS 1.2 specification. Internet services are gradually transitioning to this protocol. The main differences include:
The separation of key matching and authentication algorithms from cipher suites.
The ending of support for unstable and less-used named elliptic curves.
The ending of support for MD5 and SHA-224 cryptographic hash functions.
The need for digital signatures even when using the previous configuration.
The integration of the HMAC-based key generation function and a semi-ephemeral DH sentence.
The introduction of support for a one-time resumption of the receive-transmit session (Round Trip Time or 1-RTT) handshakes, and initial support for zero time for resuming the receive-transmit session (the name of the 0-RTT mode).
Session keys obtained using a set of long-term keys can no longer be compromised when attackers gain access to them. This property is called perfect direct secrecy (PFS) and is implemented through the use of ephemeral keys during the DH key agreement.
The ending of support for many insecure or outdated functions, including compression, renegotiation, ciphers other than AEAD-block encryption modes (Authenticated Encryption with Associated Data), non-PFS key exchange (including static RSA key exchange and static DH key exchange), configurable EDH groups, elliptic curve point ECDH format negotiation, encryption modification specification protocol, UNIX time welcome message, etc.
The prevention of SSL or RC4 negotiation that was previously possible to ensure backward compatibility.
The ceasing of use of a record-level version number and fixing the number to improve backward compatibility.
The addition of the ChaCha20 stream cipher with the Poly1305 message authentication code.
The addition of digital signature algorithms Ed25519 and Ed448.
The addition of the x25519 and x448 key exchange protocols.
The addition of support for sending multiple responses to the Online Certificate Status Protocol, OCSP.
The encryption of all confirmations of receiving and transmitting a block of data after calling the server.
2.3 What Is PKI (Public Key Infrastructure)?
Public Key Infrastructure (PKI) is a system of software, hardware and regulatory methods that solve cryptographic tasks based on a pair of private and public keys. The PKI is based on the exclusive trust of the exchange participants in the certifying center in the absence of information about each other. The certifying center, in turn, confirms or refutes the ownership of the public key to the specified person who owns the corresponding private key.
The main components of PKI:
The certifying center or Certification Center is an organization that performs, among other things, legal verification of data on participants in a network interaction (client or server). From a technical point of view, the Certification Center is a software and hardware complex that manages the lifecycle of certificates, but not their direct use. It is a trusted third party.
A public key certificate (most often just ‘certificate’) consists of client or server data and public key signed with the electronic signature of the Certifying Center. The issuance of a public key certificate by a Certification Authority ensures that the person specified in the certificate also owns the private part of a single key pair.
Registration Center (RC) is an intermediary of the Certification Center that acts on the basis of trust in the root Certification Center. The Root Certification Center trusts the data received by the Registration Center while verifying the information about the subject. After verifying the authenticity of the information, the Registration Center signs it with its own key and transmits the data it has received to the root Certification Center. The Root Certification Authority verifies the registration authority’s signature and, if successful, issues a certificate. One Registration Center can work with several Certification Centers (in other words, it can consist of several PKIs), just as one Certification Center can work with several Registration Centers. This component may not be present in the corporate infrastructure.
Repository – a repository of valid certificates and a list of revoked certificates that are constantly updated. The list of revoked certificates (Certificate Revocation List, CRL) contains data on issued certificates whose paid period or validity period have elapsed, as well as certificates of resource owners that have been compromised or have not been authenticated. In the Federal Law of the Russian Federation No. 63 "On Electronic Signatures", this component is called the register of signature key certificates.
A Certificate Archive is a repository of all certificates ever issued (including expired certificates) within the current PKI. The certificate archive is used for security incident investigations, which include verifying all data that has ever been signed.
The Request Center is the personal account of the Certification Center’s clients, where end users can request a new certificate or revoke an existing one. It is implemented most often in the form of a web interface for the registration center.
End users are clients, applications, or systems that own a certificate and use the public key management infrastructure.
3. How the Browser Works with SSL Certificates
3.1 What Happens in the Browser When the Certificate Is Checked?
Regardless of any extensions, browsers should always check a certificate’s basic information, such as the signature or the publisher. Steps for verifying Certificate Information:
1. Checking the integrity of the certificate. This is done with the cryptographic Verify operation with a public key. If the signature is invalid, then the certificate is considered fake: it has been modified after it was issued by a third party, so it is rejected.
2. Verifying the validity of the certificate. This is done with the cryptographic Decrypt operation, and by reading the accompanying information. The certificate is considered valid as long as the period for which the client has paid has not elapsed, or the expiration date has not passed. The expiration date of the certificate is the length of time for which the owner’s identity is validated by the Certifying Center that issued the certificate. Browsers reject any certificates with an expiration date that has expired before or started after the date and time of verification.
3. Checking the certificate revocation status. This is done with the cryptographic Decrypt operation, and loading and reconciliation with CRL. A number of circumstances, for example, law enforcement agencies’ appeals, the identification of a change in the source information or confirmation of the fact that the server's private key has been compromised, can make the certificate invalid before its expiration date. To do this, the certificate is added to the CRL on the side of the Certifying Center.
Certification authorities periodically release a new version of the signed CRL, and it is distributed in public repositories. Browsers access the latest version of the CRL when verifying the certificate. The main drawback of this approach is that it limits verification to the CRL issuance period. The browser will be informed of the revocation only after it receives the current CRL. Depending on the policy of the signing Certification Authority, the CRL update period can be calculated in weeks.
When working with TLSv2 and TLSv3, the browser can use the OCSP Network Certificate Status detection protocol described in RFC 6960. OCSP allows the browser to request the revocation status of a particular certificate online (the reply operation). If the OCSP is configured correctly, the verification of certificates in the CRL is much faster and avoids the use of actually revoked certificates until the next CRL update. There is an OCSP Stapling technology that allows you to include a copy of the response to the certificate status request from the Certifying Center in the headers of the HTTP responses of the web server, which in turn increases the performance and speed of data exchange.
4. Verification of the certificate publisher by the certificate chain.
Certificates are usually associated with several Certification Authorities: the root authority, which is the owner of the public key for signing certificates, and a number of intermediary ones, which refer to previous owners of the public key all the way up to the root one.
Browsers check the certificates of each Certifying Authority for being in the chain of trust with the root at the head. For added security, most PKI implementations also verify that the public key of the Certifying Authority matches the key with which the current certificate was signed. Thus, self-signed certificates are determined, because they have the same publisher only on the server where they were issued, or were added to the list of root certificates.
The X.509 v3 format allows you to determine which chain certificates should be checked. These restrictions rarely affect the average Internet user, although they are quite common in corporate systems at the development and debugging stage.
5. Checking the domain name restriction
The certification authority may restrict the validity of the certificate on a server with a specific domain name or a list of the organization's child domains. Domain name restrictions are often used for intermediate Certification Authority certificates purchased from a publicly trusted Certification Authority to exclude the possibility of issuing valid certificates for third-party domains.
6. Checking the certificate issuance policy
The Certificate Issuance Policy is a legal document published by the Certification Authority, which describes in detail the procedures for issuing and managing certificates. Certification authorities can issue a certificate in accordance with one or more policies, links to which are added to the information of the issued certificate so that the verifying parties can validate these policies before deciding whether to trust this certificate. For example, restrictions may be imposed on the region or time frame (for the period of technological maintenance of the Certification Center software).
7. Checking the length of the certificate chain
The X.509 v3 format allows publishers to define the maximum number of intermediate certification authorities that can support a certificate. This restriction was introduced after the possibility of forgery of a valid certificate was demonstrated in 2009 by including a self-signed certificate in a very long chain.
8. Verifying the public key assignment
The browser checks the purpose of the public key contained in the certificate encryption, signatures, certificate signature and so on. Browsers reject certificates, for example, if a server certificate is found with a key intended only for CRL signing.
9. Checking the rest of the chain certificates
The browser checks each certificate of the chain. If the verification data was completed without errors, then the entire operation is considered valid. If any errors occur, the chain is marked as invalid and a secure connection is not established.
3.2 How to View Certificate Information and Check that Everything Is Working Correctly
The security certificate can be checked directly in the browser. All modern browsers display certificate information visibly in the address bar. If a secure connection with a web resource is established, a lock icon is displayed on the left of the browser address bar. In case of an error, the crossed-out word "HTTPS" or an open lock icon will be displayed. Depending on the type of browser and its version, the type of icons and behavior when working with SSL certificates may differ. Below are examples of images for different versions of modern browsers:
Google Chrome
Mozilla Firefox
Opera
Microsoft Edge
Chrome for Android
Safari for iOS
To view the details of the certificate, click on the lock icon and in the subsequent menu, click on the option that outlines the security details. Information about the certificate will appear after clicking on the appropriate button or information link.
Google Chrome
Mozilla Firefox
Microsoft Edge
Chrome for Android
3.3 A Message that the Browser Does Not Trust the Certificate
Most browsers display a security warning. These warnings inform you that the certificate has not been verified by a trusted certificate authority.
There are a number of reasons why an SSL certificate may be considered invalid in the browser. The most common reasons are:
Errors in the certificate chain installation process, the intermediate certificate is missing;
The SSL certificate has expired;
The SSL certificate is valid only for the primary domain, not for subdomains;
A self-signed SSL certificate has been used, or the root certificate of the Certification Authority has not been added to the trusted list on the current device.
4. Certification Centers
4.1 More Details about the Certification Centers
As mentioned above, the main task of the Certification Center is to confirm the authenticity of encryption keys using electronic signature certificates. The overarching operating principle can be described by the phrase "users do not trust each other, but everyone trusts the Certifying Center."
Any HTTPS interaction is based on the fact that one participant has a certificate signed by the Certification Authority, and the other attempts to verify the authenticity of this certificate. Verification will be successful if both participants trust the same Certification Authority. To solve this problem, the Certification Center’s certificates are preinstalled in operating systems and browsers. If the Certification Authority itself has issued a certificate, it is called a root certificate. A certificate issued by a partner of the Certification Authority with which it has a trust relationship is called an intermediate certificate. As a result, a tree of certificates is formed with a chain of trust between them.
By installing the certificate of the Certifying Center in the system, you can trust the certificates that have been signed with it. A certificate (particularly for HTTPS) that is issued but not signed by a root or intermediate Certification authority is called a self-signed certificate and is considered untrusted on all devices where this certificate is not added to the root/intermediate lists.
According to the distribution level of certificates, the Certification Center can be international, regional, and corporate. The public key management infrastructure’s activities are carried out in accordance with the regulations of the appropriate level: i.e. public directives recorded by the international community of Internet users, the legislation of the region, or the relevant provisions of the organization.
The main functions of the certification center are:
verifying the identity of future certificate users;
issuing certificates to users;
revoking certificates;
maintaining and publishing lists of revoked certificates (Certificate Revocation List/CRL), which are used by public key infrastructure clients when they decide whether to trust a certificate.
Additional functions of the certification center are:
Generating key pairs, one of which will be included in the certificate.
Upon request, when resolving conflicts, the UC can verify the authenticity of the electronic signature of the owner of the certificate issued by this UC.
Browsers and operating systems of devices fix the trust of the Certifying Center by accepting the root certificate into their storage – a special database of root certificates of Certifying centers. The storage is placed on the user's device after installing the OS or browser. For example, Windows maintains its root certificate store in operating systems, Apple has a so-called trust store, Mozilla (for its Firefox browser) creates a separate certificate store. Many mobile operators also have their own storage. Regional and corporate should be added either at the stage of software certification in the country, or by contacting the technical support of the organization.
Regional representatives of the world Certification Centers have the authority to make legal requests for the activities of organizations related to the publication of web resources. For corporate Certification Centers, this is not necessary, since they usually have access to the internal information of the organization. For security purposes, Certification Authorities should not issue digital certificates directly from the root certificate transmitted to operators, but only through one or more Intermediate Certificate Authority, ICA. These intermediate Certification Authorities are required to comply with security recommendations in order to minimize the vulnerability of the root Certification authority to hacker attacks, but there are exceptions. For example, GlobalSign is one of the few certification authorities that have always (since 1996) used ICA.
Certificates come in different formats and support not only SSL, but also the authentication of people and devices, as well as certifying the authenticity of code and documents. Within the Russian legislative framework, such activities must be licensed by the FSB, since they are related to cryptographic operations.
The universal algorithm for obtaining a certificate from the Certification Center:
1. Private key generation 2. Creation of a certificate signing request (CSR request) 3. Procurement of a certificate signed by the Certificate Authority’s root certificate after passing the checks 4. Configuration of the web server for your resource
Since browsers have a copy of the international Certification Authority’s root certificate, as well as a number of intermediate certificates from the chain of trust, the browser can check whether a certificate was signed by a trusted certification authority. When users or an organization create a self-signed certificate, the browser does not trust it as it knows nothing about the organization, so the root certificate of the organization must be manually added to all controlled devices. These certificates will become trusted after this.
4.2 What Are Root Certificates?
A root certificate is a file that contains service information about the Certification Authority. Special software or a library that verifies, encrypts and decrypts information is called a crypto provider (a provider of cryptographic functions). The cryptographer gets access to the encrypted information, thereby confirming the authenticity of the personal electronic signature.
A chain of trust for the certificates is then built based on the certifying center’s root certificate. Any electronic signature issued by the Certifying Center only works if there is a root certificate.
The root certificate stores information with the dates of its validity. The cryptographic provider can also get access to the organization's registry through the root certificate.
4.3 What Is a Certificate Chain?
Historically and technologically, certain Certification Centers are widely recognized among SSL users, and as a result, it was agreed that the certificates they issued would be considered root certificates, and they would always be trusted. Regional Certifying certificates, in turn, can be confirmed by the root Certifying center. In turn, they can confirm other certificates, forming a chain of trust to certificates. The Certifying Center acts as a guarantor-certifier which issues an SSL certificate at the request of the owner of a web resource.
The certificate and the web resource to which it is issued are certified by an electronic digital signature (EDS). This signature indicates who the owner of the certificate is and records its contents, that is, it allows you to check whether it has been changed by someone after it was issued and signed.
The list of certificates of root Certifying centers and their public keys is initially placed in the operating system’s software storage on the users' workstation, in the browser, and in other applications that use SSL.
If the chain of sequentially signed certificates ends with the root certificate, all certificates included in this chain are considered confirmed.
Root certificates located on the user's workstation are stored in a container protected by the operating system from accidental access. However, the user can add new root certificates themselves, and this is a source of potential security problems.
By carrying out certain actions and accessing an attacked workstation, an attacker can include their own certificate among the root certificates and use it to decrypt the data that is received.
The Root Certification Center can be formed by the government of a particular country or the leaders of an organization. In these cases, root Certification Centers will not operate everywhere, but they can nonetheless be used quite successfully in a specific country or within a specific enterprise.
At present, the list of root certification authorities on the user's computer can be automatically changed when updating the operating system, software products, or manually by the system administrator.
Certification centers can issue a variety of SSL certificates linked by what is known as a tree structure. The root certificate is the root of the tree, with the secret key with which other certificates are signed. All intermediate certificates that are at a lower level inherit the degree of trust that the root certificate has. SSL certificates located further down the structure receive trust in the same way from the Certifying Centers located higher up the chain. Using the example of the Comodo Certification Center, the structure of SSL certificates can explained as follows:
1. The root certificate of the Comodo Certification Authority: AddTrustExternalCARoot
2. Intermediate Certificates: PositiveSSL CA 2, ComodoUTNSGCCA, UTNAddTrustSGCCA, EssentialSSLCA, Comodo High-Assurance Secure Server CA
3. SSL certificates for individual domains
5. General Information about Certificate Types
5.1 Paid Trusted Certificates
The purchase of trusted certificates, except in some cases, is a paid service.
5.1.1 Where and How to Buy
In most cases in Russia, web resource hosting companies or partner organizations of international Certification centers provide SSL certificate services. It is possible to purchase certificates directly from Certification Centers, but such certificates are usually more expensive than from partners who purchase them in bulk.
The procedure for purchasing an SSL certificate is no different from purchasing other internet services. It entails:
1. Selecting a supplier and going to the SSL certificates order page.
2. Selecting the appropriate SSL certificate and clicking the purchase button.
3. Entering the name of your domain and selecting the protection option — for one domain or Wildcard certificate for a group of subdomains.
4. Paying for the service in whichever way is most convenient.
5. Continue configuring the service in accordance with the following parameters:
a. The number of domains that the certificate protects (i.e. one or more). b. Subdomain support. c. The speed of release. Certificates with domain-only validation are issued the quickest, while certificates with EV validation are issued the slowest. d. Most Certifiers offer unlimited certificate reissues. This is required if there are mistakes in the organization data. e. Warranty – for some certificates there is a $10,000 warranty. This is a guarantee not for the certificate buyer, but rather for the visitor of a site that installs a certificate. If a site visitor with such a certificate suffers from fraud and loses money, the Certification Center undertakes to compensate the stolen funds up to the amount specified in the guarantee. In practice, such cases are extremely rare. f. Free trial period – Symantec Secure Site, Geotrust Rapidssl, Comodo Positive SSL, Thawte SSL Web Server certificates have paid certificates. There are also free certificates. g. Refund – almost all certificates have a 30-day refund policy, although there are certificates without this.
5.1.2 Approximate Cost
SSL certificates can be separated into different groups based on their properties.
1. Regular SSL certificates. These are issued instantly and confirm only one domain name. Cost: from $20 per year
2. SGC certificates. These support customers with increasing the level of encryption. Server Gated Cryptography technology allows you to forcibly increase the encryption level to 128 bits in older browsers that supported only 40 or 56 bit encryption. Cryptography is used to solve this problem, but it cannot cope with the other vulnerabilities present in unsecure browsers, so there are a number of root Certification centers that do not support this technology. Cost: from $300 per year.
3. Wildcard certificates. They provide encryption of all subdomains of the same domain by mask. For example, there is a domain domain.com; if the same certificate must be installed on support.domain.com , forum.domain.com and billing.domain.com , customers can issue a certificate for *.domain.com . Depending on the number of subdomains that need the certificate, it may be more cost-effective to purchase several ordinary SSL certificates individually. Examples of wildcard certificates: Comodo PositiveSSL Multi-Domain Wildcard and Comodo Multi-Domain Wildcard SSL. Cost: from $180 per year.
4. SAN Certificates Subject Alternative Name technology allows customers to use one certificate for several different domains hosted on the same server. Such certificates are also referred to as UCC (Unified Communication Certificate), MDC (Multi-domain certificate) or EC (Exchange Certificate). Generally, one SAN certificate includes up to 5 domains, but this number can be increased for an additional fee. Cost: from $395 per year.
5. Certificates with IDN support Certificates with national domain support (International Domain Name, such as *.RU, *.CN, *.UK). Not all certificates can support IDN. This must be clarified with the Certification Center. Certificates supporting IDN include:
Thawte SSL123 Certificate;
Thawte SSL Web Server;
Symantec Secure Site;
Thawte SGC SuperCerts;
Thawte SSL Web Server Wildcard;
Thawte SSL Web Server with EV;
Symantec Secure Site Pro;
Symantec Secure Site with EV;
Symantec Secure Site Pro with EV.
As is mentioned above, partners of Certification Centers can provide significant discounts on prices — starting at $10 — or offer service packages.
5.1.3. Certificate Validation
Certificates are divided into the following levels of validation:
1. DV
Domain Validation, or certificates with domain validation. The certification authority verifies that the client who requests the certificate controls the domain that needs the certificate. A network service for verifying the ownership of WHOIS web resources is used to do this. This type of certificate is the cheapest and most popular, but it is not completely secure, since it contains only information about the registered domain name in the CN field (CommonName is the common domain name of a web resource).
2. OV
Organization Validation, or certificates with organization verification. The certification center verifies the affiliation of a commercial, non-profit or government organization to the client, who must provide legal information when purchasing. This type of certificate is seen as more reliable, since it meets the RFC standards and also confirms the registration data of the owner company in the following fields:
O (Organization – name of the organization);
OU (Organizational Unit – name of the organization's division);
L (Locality – name of the locality of the organization’s legal address);
S (State or Province Name – name of the territorial and administrative unit of the organization’s legal address);
C (Country Name – the name of the organization's country).
The certification center can contact the company directly to confirm this information. The certificate contains information about the person that confirmed it, but not data about the owner. An OV certificate for a private person is called IV (individual validation/ individual verification) and verifies the identity of the person requesting the certificate.
3. EV
Extended validation, or a certificate with extended validation. The Certification Center verifies the same data as the OV, but in accordance with stricter standards set by CA/Browser Forum. CA/Browser Forum (Certification Authority Browser Forum)is a voluntary consortium of certification authorities, developers of Internet browsers and software for secure email, operating systems, and other applications with PKI support. The Consortium publishes industry recommendations governing the issuing and management of certificates. This type of certificate is considered the most reliable. Previously, when using these certificates in a browser, the color of the address bar changed and the name of the organization was displayed. It is widely used by web resources that conduct financial transactions and require a high level of confidentiality. However, many sites prefer to redirect users to make payments to external resources confirmed by certificates with extended verification, while using OV certificates which are secure enough to protect the rest of the user data.
5.1.4. The Setup Process (General Information, What Is CSR?)
To initiate the certificate issuing process, a CSR request must be made. Technically, a CSR request is a file that contains a small fragment of encrypted data about the domain and the company to which the certificate is issued. The public key is also stored in this file.
The CSR generation procedure depends entirely on the software used on your server, and is most often performed using the settings in the administrative panel of your hosting. If your hosting does not provide this, then you can use online services to generate a CSR request, or alternatively you can turn to specialized software, such as OpenSSL, GnuTLS, Network Security Services, etc. After generating the CSR, the private key will also be generated.
To successfully generate a CSR, you need to enter data about the organization that has requested the certificate. The information must be entered in the Latin alphabet. The following parameters are sufficient:
Country Name — the country of registration of the organization in two-letter format. For the Russian Federation — RU;
State or Province Name — region, region of registration of the organization. For Moscow — Moscow;
Locality Name — the city where the organization is registered. For Moscow — Moscow;
Organization Name — the name of the organization. For individuals, "Private Person" is indicated;
Common Name — the domain name of those who have requested the certificate;
Self–signed certificates are SSL certificates created by the service developers themselves. A pair of keys for them is generated through specialized software, for example, OpenSSL. Such a communication channel may well be used for internal purposes, i.e. between devices within your network or applications at the development stage.
5.3. Let’s Encrypt
Let's Encrypt is an Authentication Center that provides free X.509 cryptographic certificates for encrypting HTTPS data transmitted over the Internet and other protocols used by servers on the Internet. The process of issuing certificates is fully automated. The service is provided by the public organization Internet Security Research Group (ISRG).
The Let's Encrypt project was started to translate most of the Internet sites to HTTPS. Unlike commercial Certification centers, this project does not require payment, reconfiguration of web servers, use of e-mail, or the processing of expired certificates. This simplifies the installation and configuration of TLS encryption. For example, on a typical Linux-based web server, you need to run two commands that will configure HTTPS encryption, receive and install a certificate in about 20-30 seconds.
Let's Encrypt root certificates are installed as trusted by major software vendors, including Microsoft, Google, Apple, Mozilla, Oracle and Blackberry.
The Let's Encrypt Certification Authority issues DV certificates with a validity period of 90 days. It has no plans to start issuing OV or EV Certificates, although it began providing support for Wildcard certificates some time ago.
The key to the root certificate of the RSA standard has been stored in the HSM hardware storage since 2015 and is not connected to the network. This root certificate is signed by two intermediate root certificates, which were also signed by the IdenTrust certification authority. One of the intermediate certificates is used to issue sites’ final certificates, while the second is kept as a backup in storage that is not connected to the Internet, in case the first certificate is compromised. Since the root certificate of the IdenTrust center is preinstalled in most operating systems and browsers as a trusted root certificate, the certificates issued by the Let's Encrypt project are verified and accepted by clients — despite the absence of the ISRG root certificate in the trusted list.
The Automated Certificate Management Environment (ACME) authentication protocol is used to automatically issue a certificate to the destination site. In this protocol, a series of requests are made to the web server that seeks a signature for the certificate to confirm the ownership of the domain (DV). To receive requests, the ACME client configures a special TLS server, which is polled by the ACME server using Server Name Indication (Domain Validation using Server Name Indication, DVSNI).
Validation is carried out repeatedly, using different network paths. DNS records are pulled from a variety of geographically distributed locations to prevent DNS spoofing attacks. This is when domain name cache data is changed by an attacker in order to return a false IP address and redirect the intermediary to the attacker's resource (or any other resource on the network)1.
6. Paid Trusted Certificates
6.1 Usage on Windows Server and IIS
6.1.1 What Are the Formats of the Private Key?
These are today’s private key formats:
1. PEM format
This format is most often used by Certification Authorities. PEM certificates most often have extensions *.pem, *.crt, *.cer or *.key (for private keys) and others. For example, the package file SSL.com The CA available in the download table in the order of the certificate has the extension *.ca-bundle. The contents of the files are encrypted using Base64 and contain the strings "--BEGIN CERTIFICATE--" and "--END CERTIFICATE--".
This certificate format is common in Linux OS. Multiple PEM certificates and even a private key can be included in one file, one under the other. But most servers, such as Apache, expect the certificate and private key to be in different files.
2. PKCS#7/P7B format
PKCS#7 or P7B format certificates are usually saved in Base64 ACVII format and have the extension *.p7b or *.p7c. The P7B certificate contains the strings "--BEGIN PKCS7--" and "--END PKCS7--". This format contains only the certificate and certificate chain, but not the private key. Several commonly-used platforms support this format, including Microsoft Windows and Java Tomcat.
3. PKCS#12/PFX format
PKCS#12 or PFX format is a binary format for saving a certificate, any intermediate certificates, and a private key in one encrypted file. PFX files are usually saved with the extension *.pfx or *.p12. As a rule, this format is used on Windows certificates to export/import the certificate and private key 2.
6.1.2 How to Generate a CSR Request
To generate a CSR request in IIS 10, perform the following operations:
1. Run IIS from the iis.msc command line or from the visual interface.
2. Select your server from the Connections list and click the Server Certificates button.
3. On the Server Certificates page, click the Create Certificate Request link in the Actions block.
4. In the Request Certificate window of the wizard, fill in the CSR fields and click Next.
5. In the Cryptographic Service Provider Properties window of the wizard, select the required cryptographic provider, depending on the desired algorithm and the key length, and then click Next.
6. In the File Name window of the wizard, specify the path to the CSR being created, and then click Finish.
To send the finished CSR to the Certification Center, open the file in a text editor and copy the contents to the web form of the certificate provider.
6.1.3 How to Create a Private Key
As a result of creating the CSR, the private key will be created automatically by IIS. Viewing is available on the Certificates console snap-in in the Personal or Web Hosting points of the certificate tree.
The snap-in can be hidden in the console. To add it, run the mmc command in Start menu > Run and in the window that appears, add the Certificates snap-in to the list available on the local machine:
6.1.4 How to Export It
To export a private key for backup purposes or to configure a new server, follow these steps:
1. Find the certificate in the Certificates snap-in of the management console, and right-click on it. In the context menu that appears, click on the menu item All Tasks > Export;
2. In the Welcome to the Certificate Export wizardwindow of the Certificate Export Wizard, click Next and then in the Export Private Key window, set the switch to Yes, export the private key, and then click Next;
3. In the Export File Format window of the wizard, select the type item Personal Information Exchange – PKCS #12 (.PFX) and select the checkbox Include all certificates in the certification path if possible. Then click Next. Be aware that if the Delete the private key if the export is successful checkbox is checked, the private key created on the current server will be deleted after export;
4. In the Security wizard window, fill the Password checkbox and enter the password twice to protect the private key. It will be required for the subsequent import. Additionally, it is recommended that Active Directory users or groups that have the ability to use a private key are restricted. To do this, fill the Group or User Name checkbox and select Required Groups or Users, then click Next;
5. In the File to Export window of the wizard, specify the path to the exported file with the private key and its name. To do this, enter it manually or use the system file search dialog box, then click Next;
6. In the File to Export window of the wizard, specify the path to the exported file with the private key and its name. To do this, enter it manually or use the system file search dialog box, and then click Next. In the next window Completing the Certificate Export Wizard, a list of the installed settings will appear. Click Finish. The exported file will appear in the specified directory.
6.1.5 How to Configure SSL on IIS
To configure SSL in IIS, follow these steps:
1. Run IIS from the iis.msc command line or from the visual interface.
2. Select your server from the Connections list and click on the Bindings... link in the Actions block.
3. In the Site Bindings window, click Add.
4. In the Add Site Bindings window, fill in the following fields and click OK.
IP address – select the IP addresses of the servers with which the certificate will be associated from the drop-down list or click the All Unassigned button to associate the certificate with all servers.
Port – leave the value 443. This is a standard SSL port.
SSL certificate – select the required SSL certificate from the drop-down list.
The setup is finished, you can check the operation of the web service. If the private key is missing, then import it in the Certificates snap-in of the Management console. To do this, select the desired resource and right-click on it. Then, in the context menu that appears, click on the menu item All Tasks > Import, and follow the instructions of the wizard.
6.2 Usage on Linux
6.2.1 How to Create a Private Key
The private key that has been created can be obtained in the interface of the SSL certificate provider after sending the CSR or using specialized software, such as OpenSSL, for example.
Below is a fragment of private key generation in the web interface of the SSL certificate provider.
If the private key was created in the web interface, then the export is carried out by clicking the button there. After clicking on the button, the browser starts downloading the archive with the key file in the desired format.
To create a private RSA key using OpenSSL, one command is enough:
openssl genrsa -out rsaprivkey.pem 2048
This command generates the PEM private key and stores it in the rsaprivkey.pem file. In our example, a 2048-bit key is created, which is suitable for almost all situations.
To create a DSA key, you need to perform two steps:
The first step creates a DSA parameters file (dsaparam.pem), which in this case contains instructions for OpenSSL to create a 2048-bit key in step 2. The dsaparam.pem file is not a key, so it can be deleted after the public and private keys are created. In the second step, a private key is generated (dsaprivkey.pem file), which must be kept secret.
To create a file in the PKCS#12 format used in Windows OS, use the following command:
export – the operation of exporting the private key to the required format;
out – the directory in the file system where the resulting file should be placed;
inkey – private key file in PEM format;
in – file of the certificate received from the Certifying Center;
certfile is a copy of the root certificate and intermediate certificates in the chain. In the example above, they are missing.
6.2.2 How to Generate a CSR Request
To generate a CSR, fill in the suggested fields in the web form of the SSL certificate service provider. The figure above demonstrates an example of this. The set of minimum required fields is the same and is given in the section about CSR description, but some vendors can add their own or change the input method.
To generate CSR using OpenSSL, use the following command:
new – creating a new CSR request by direct input in the console. Without this option, the OpenSSL configuration file data will be used;
key – the name of the private key required for generation. If the option is not specified, a new private key will be created according to the default algorithm;
out – the path to the CSR file being created;
sha256 is an encryption algorithm.
After executing the command, a request to fill in the required fields will appear in the console.
Then send the resulting CSR to the Certifying Center. In response, a personal certificate must be returned.
6.2.3 How to Configure SSL for Apache
Follow these steps to configure SSL in Apache:
1. Add the personal certificate issued by the Certification Authority, the private key, and the root certificate to the /etc/ssl/ directory — along with the rest of the certificates in the chain.
2. Open the Apache configuration file with any text editor: vim, for example. Depending on the server OS, the file may be located in one of the following locations:
for CentOS: /etc/httpd/conf/httpd.conf;
for Debian/Ubuntu: /etc/apache2/apache2.conf;
3. If you are installing an SSL certificate on an OpenServer, use the path to its root folder. At the end of the file, create a copy of the "VirtualHost" block. Specify port 443 for the block and add the following lines inside:
SSLEngine on
SSLCertificateFile /etc/ssl/domain_name.crt
SSLCertificateKeyFile /etc/ssl/private.key
SSLCertificateChainFile /etc/ssl/chain.crt
4. Check the Apache configuration before restarting with the command: apachectl configtest, then restart Apache.
6.2.4 How to configure SSL for Nginx
Follow these steps to configure SSL in Nginx:
1. Open a text editor and add the contents of the personal certificate issued by the Certification Authority, and the root certificate — along with the rest of the certificates in the chain. The resulting file should look like this:
2. Save the resulting file with the *.crt extension to the /etc/ssl/ directory. Please note: the second certificate should come directly after the first, without any empty lines.
3. Save the your_domain file.key with the certificate's private key in the /etc/ssl directory.
4. Open the Nginx configuration file and edit the virtual host of your site that you want to protect with a certificate. Perform the minimum setup for the job by adding the following lines to the file:
/etc/ssl/your_domain.crt — the path to the file created with three certificates;
/etc/ssl/your_domain.key — the path to the file with the private key.
The names of files and directories can be arbitrary.
Additionally, you can configure the operation of the site over HTTP, the type of server cache, the cache update timeout, and the operating time of a single keepalive connection. You can also configure the supported protocols and their level of priority (server set or client set), as well as OCSP responses for certificate validation. Details are given in the Nginx user manual.
5. For the changes to take effect, restart the Nginx server with the following command:
sudo /etc/init.d/nginx restart
7. Self-Signed Certificates
7.1 Usage on Windows Server and IIS
7.1.1 How to Create a Private Key
You can create a private key with IIS by creating a CSR and then actioning the above instructions.
7.1.2 How to Create a Self-Signed Root Certificate
To generate a self-signed root certificate in IIS 10, perform the following operations:
1. Run IIS from the iis.msc command line or from the visual interface.
2. Select your server from the Connections list and click on the Server Certificates button.
3. On the Server Certificates page, click the Create Domain Certificate link in the Actions block.
4. In the Distinguished Name Properties window of the Create Certificate wizard, fill in the Common Name field (the server name specified in the browser), the remaining fields that were filled when creating the CSR, and click Next.
5. In the Online Certification Authority window of the wizard, specify in the Specify Online Certification Authority field the repository where you want to place the root certificate. In the Friendly Name field, specify the name of the certificate, and then click Finish.
7.1.3 How to Create an SSL Certificate Signed by the Root
To generate a self-signed SSL certificate in IIS 10, perform the following operations:
1. Run IIS from the iis.msc command line or from the visual interface.
2. Select your server from the Connections list and click on the Server Certificates button.
3. On the Server Certificates page, click the Create Self-Signed Certificate link in the Actions block.
4. In the ‘Create Self-Signed Certificate’ window in the ‘Friendly Name’ field, specify the name of the certificate in the ‘Select a Certificate Store for the New Certificate’ field. Then, select the repository in which the self-signed certificate will be stored, and click OK.
7.1.4 How to Configure IIS for a Self-Signed Certificate
IIS configuration for Configuring IIS for a self-signed certificate requires the same process as a certificate issued by a Certification Authority.
7.2 Usage on Linux
7.2.1 How to Create a Private Key
Creating a private key using the genrsa command and other similar ones in OpenSSL is described above.
7.2.2. How to Create a Self-Signed Root Certificate
To generate a self-signed root certificate in OpenSSL, run the following command:
7.2.4. How to Configure Apache for a Self-Signed Certificate
Apache configuration for a self-signed certificate is performed in the same way as for a certificate issued by a Certification Authority.
7.2.5. How to Configure Nginx for a Self-Signed Certificate
Nginx configuration for a self-signed certificate requires the same process as a certificate issued by a Certification Authority.
7.3 How to Make Self-Signed Certificates Trusted
7.3.1 On Windows
To make a self-signed certificate trusted, follow these steps:
1. Find the repository of trusted certificates in the Certificates snap-in of the management console. Right-click on it, and then in the Context Menu that appears, click on the menu item All Tasks > Import;
2. In the Welcome to the Certificate Import wizard window of the Certificate Import wizard, click Next. Then, in the File to Import window, specify the path to the imported file with the self-signed certificate. To do this, either enter it manually or use the system file search dialog box. Afterwards, click Next.
3. In the Private Key Protection window of the wizard, enter the password specified when creating the self-signed certificate. Set the checkboxes Mark this key as exportable to allow further export of the certificate for backup purposes, and Include all extended properties, then click Next. Further export will only work if the private key is available.
4. In the Certificate Store window of the wizard, turn on Place all certificates in the following store, select the Trusted Root Certification Authorities repository, and then click Next. In the next window Completing the Certificate Import Wizard, you will see a list of the installed settings. Click Finish. The imported file will appear in the specified repository.
7.3.2 On macOS
To add a self-signed certificate to trusted certificates, follow these steps:
1. Open the Keychain Access application by clicking on the icon below and go to the All Items menu item.
2. Use Finder to find the self-signed certificate file (*.pem, *.p12 or other).
3. Drag the file to the left side of the Keychain Access window.
4. Go to the Certificates menu item, find the self-signed certificate that has been added and double-click on it.
5. Click on the Trust button in the drop-down menu and set the When using this certificate field from System Defaults to Always Trust.
7.3.3 On Linux
To add a self-signed certificate to trusted ones in Linux OS (Ubuntu, Debian), follow these steps:
1. Copy the root self-signed certificate file to the /usr/local/share/ca-certificates/ directory. To do this, run the command sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt, where foo.crt is the personal certificate file.
2. Run the sudo update-ca-certificates command.
To add a self-signed certificate to trusted certificates in Linux OS (CentOS 6), follow these steps:
1. Install the root certificates using the command: yum install ca-certificates.
2. Enable the dynamic configuration mode of root certificates: update-ca-trust force-enable.
3. Add the certificate file to the directory /etc/pki/ca-trust/source/anchors/: cp foo.crt /etc/pki/ca-trust/source/anchors/.
4. Run the command: update-ca-trust extract.
7.3.4 On iOS
To add a self-signed certificate to trusted certificates, follow these steps:
1. Install any web server and place the certificate file in the root of the application directory.
2. Go to the URL of the web server, after which the file will be downloaded to the profile of the current user.
3. Open the Profiles menu and click Install.
4. Go to Settings > General > About-> Certificate Trust Settings and set the switch for the certificate to Enabled.
7.3.5 On Android
To make a self-signed certificate trusted, follow these steps:
1. Download the file to the device.
2. Go to Settings > Security > Credential Storage and tap Install from Device Storage.
3. Find the *.crt that has been downloaded and enter its name in the Certificate Name field. After it has been imported, the certificate will be displayed in Settings > Security > Credential Storage > Trusted Credentials > User.
7.3.6 How to Make a Root Certificate Trusted in Windows AD Group Policies
To make a root certificate trusted in Windows Active Directory Group Policies, follow these steps:
1. Run the Group management snap-in from the gpmc.msc command line.
2. Select the desired domain, right-click on it, and select Create a GPO in this domain and link it here.
3. Specify the name of the group policy in the window that appears and click OK.
4. Right-click on the created group policy and click Edit.... On the next screen, go to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update. Select Allow signed content from intranet Microsoft update service location and click Edit Policy Settings.
5. Set the switch to Enabled and click OK.
6. Go to Computer Configuration>Windows Settings >Security Settings>Public Key Policies and trust the required certificate in accordance with the instructions above.
7. Repeat step 4 and close the Group Policy Editor. The policy will be applied shortly. To apply it immediately, run gpupdate /force on the command line.
8. Let’s Encrypt
8.1 Usage on Windows Server and IIS
8.1.1 How to Issue a Certificate
To install the Let's Encrypt certificate, an ACME client must be installed on the server. The following implementations are common for Windows:
The Windows ACME Simple Utility (WACS) is a command–line utility for interactively issuing a certificate and binding it to a specific site on your IIS web server;
The ACMESharp Powershell module is a Powershell library. It has many commands for interacting with Let's Encrypt servers via the ACME API;
Certify is a graphical SSL certificate manager for Windows that allows you to interactively manage certificates via the ACME API.
To issue a Let's Encrypt certificate using WACS, follow these steps:
2. Open a command prompt and run the client wacs.exe from the specified location.
3. Press the N key. This will create a certificate for IIS.
4. Select the certificate type: DV for one domain, DV for all domains in IIS (SAN), domains corresponding to Wildcard, or a manual list of domains in IIS.
5. Depending on the choice, WACS.exe will display a list of sites running on the IIS server and will prompt you to select the desired site.
6. After selecting the site, provide an email address to receive information about problems including site certificate updates (several addresses can be given if they are separated by commas).
7. Agree to the terms of use by pressing the Y key, after which Windows ACME Simple will connect to Let's Encrypt servers and try to automatically generate a new SSL certificate for the site 3.
8.1.2 How to Configure IIS for Let's Encrypt Certificate
The WACS utility saves the certificate's private key (*.pem), the certificate itself, and a number of other files to the directory C:\Users\%username%\AppData\Roaming\letsencrypt-win-simple . It will then install the generated Let's Encrypt SSL certificate in the background and bind it to your IIS site.
To install the Let's Encrypt certificate, the ACME client must be installed on the server. For Linux, this is the Certbot utility.
To issue a Let's Encrypt certificate using Certbot, follow these steps:
1. Install Certbot according to the instructions on the website https://certbot.eff.org / to the server. 2. Execute the certificate issue command: certbot --nginx or certbot --apache. When launching for the first time, an email address for receiving information about problems site certificate updates and other alerts may be required.
Certbot will analyze the ServerName directive that corresponds to the domain name with the requested certificate in the web server’s configuration files. If you need to specify multiple domains or wildcard, use the command line key -d.
8.2.2 How to Configure IIS for a Let's Encrypt Certificate
After executing the certbot command, the web server configuration will be updated automatically. The certbot client will display a successful completion message, and will also show the path to the directory where the certificates are stored.
9. Certificate Renewal for Linux and Windows
9.1 Paid Trusted
When extending the validity of the SSL/TLS certificate, creating a new CSR request is recommended. Generating a new request will create a new unique key pair (public/private) for the updated certificate.
The web interface of many SSL certificate providers allows you to renew the certificate manually or automatically. After renewing, the user will receive a new reissued certificate. This needs to be reconfigured again in accordance with the instructions above.
9.2 Self-Signed
Self-signed certificates are renewed by recreating and configuring the web server in accordance with the instructions described above.
9.3 Let’s Encrypt
9.3.1 On Windows
Windows ACME Simple creates a new rule in the Windows Task Scheduler (called win-acme-renew) to automatically renew the certificate. The task is started every day, and the certificate renewal itself is performed after 60 days. When extending, the scheduler runs the command:
C:\\<path to the WACS directory>\\wacs.exe --renew --baseuri "<https://acme-v02.api.letsencrypt.org >"
You can use the same command to manually update the certificate.
9.3.2 On Linux
To renew the certificate via certbot, you need to run the following command:
certbot Renew --force-Renewal
To specify a specific domain, use the -d parameter.
10. Testing
10.1 Services (SSL Checkers) that Allow You to Check SSL Tinctures on a Public Server
SSL verification is carried out using online services provided by Certification Centers, as well as third-party developers such as:
These services allow you to gain information about certificates, domains, organizations, cities, serial numbers, algorithms used, their parameters (such as key length) and details about the certificate chain.
10.2 Verification of the Entire Certificate Chain
The entire certificate chain is verified by SSL Shopper, Symantec SSL Toolbox and SSL Checker. The links are given above.
10.3 Checking on iOS (via a Special App)
To check certificates on iOS devices, install the SSL Checker app from the App Store. With this application, you can check the current status and validity of the SSL certificate of any server, including self-signed certificates. The application can detect changes in the certificate parameters and send notifications about it.
10.4 Checking on Android
To check certificates on Android devices, install the SSL Certificate Checker application from Google Play. Using this application, you can check the current status and attributes of the SSL certificate of any server, including the certificate chain.
Many times, we’ve mentioned self-signed certificates and their most common use cases in our blog. After all, the main difference between a regular certificate and a self-signed one is that in the latter case, you act as the CA (Certificate Authority). But there are a variety of services that provide CA services for free, with the most popular being ‘Let’s Encrypt’, which is going to be the subject of this article.
What’s that?
‘Let’s Encrypt’ is a free certificate authority developed by the Internet Security Research Group (ISRG).
It provides free TLS/SSL certificates to any suitable client via the ACME (Automatic Certificate Management Environment) protocol. You can use these certificates to encrypt communication between your web server and your users. ‘Let's Encrypt’ provides two types of certificates. Single-domain SSL and Wildcard SSL, which covers a single domain and all of its subdomains. Both types of SSL certificates have a 90-day validity period. These domain-validated certificates do not require a dedicated IP address. They accomplish this by delivering the client a unique token and then retrieving a key generated from that token via an HTTP or DNS request.
There are dozens of clients available which can be easily integrated with a variety of standard administrative tools, services, and servers. They also come written in a range of different computer languages.
We'll use the win-acme client in this tutorial because it's a basic, open-source, and constantly updated command-line application. It not only produces certificates but also automatically installs and renews them. And yes, this tutorial is for Windows users.
How does it work?
‘Let's Encrypt’ verifies the ownership of your domain before issuing a certificate. On your server, the Let's Encrypt client creates a temporary file (a token) with the required information. The Let's Encrypt validation server then sends an HTTP request to get the file and validates the token, ensuring that your domain's DNS record resolves to the ‘Let's Encrypt’ client-server.
In an HTTP-based challenge, for example, the client will generate a key from a unique token and an account token, then save the results in a file that the web server will serve. The file is then retrieved from the Let's Encrypt servers at: http://passwork.com/.well-known/acme-challenge/token.
The client has demonstrated that it can control resources on example.com if the key is correct, and the server will sign and provide a certificate.
How do I set it up?
Before we start:
Make sure that you’ve downloaded the latest version of the application on the server from its Github release page;
Scroll down to ‘assets’ and download the zip package named win-acme.v2.x.x.x.zip from the release page. If you're having difficulty with Internet Explorer, you may install Chrome on the server following this approach. Once the application has been downloaded, unpack it and save it somewhere safe for future use.
Now let’s Generate the Let’s Encrypt Certificates
Simply run wacs.exe to generate the Let's Encrypt certificates. Because we downloaded the application via the internet, you may receive a notification from Windows Defender claiming that "Windows protected your PC". Because of this, after clicking the "More Info" link, click the "Run Anyway" option. Because it’s open-source and widely utilized, the application is completely safe to use.
Follow these simple steps once the application has started:
Choose N in the main menu to create a new certificate with default settings;
Choose how you want to determine the domain name(s) that you want to include in the certificate. These may be derived from the bindings of an IIS site, or you can input them manually;
A registration is created with the ACME server if no existing one can be found. You will be asked to agree to its terms of service and to provide an email address that the administrators can use to contact you;
The program negotiates with the ACME server to try and prove your ownership of the domain(s) that you want to create the certificate for. By default, the http validation mode is picked and handled by our self-hosting plugin. Getting validation right is often the most tricky part of getting an ACME certificate. If there are problems, please check out some of the common issues for an answer;
After the proof has been provided, the program gets the new certificate from the ACME server and updates or creates IIS bindings as required, according to the logic documented here;
The program remembers all choices that you made while creating the certificate and applies them for each subsequent renewal.
And that’s pretty much it. It will successfully generate an SSL certificate for you if your domain is pointing to your server. It will also include a scheduled task that will renew the certificate when it expires. The SSL certificate will be installed automatically by the application.
Are there other options?
‘Certbot’ is the most widely used kind of ‘Let's Encrypt’ client. We didn’t give it much light in this article because it's “designed for Linux” and also a little more advanced. It comes with easy-to-use automatic configuration features for Apache and Nginx. And yes, there is a Windows version as well.
There are many other clients to choose from – the ACME protocol is open and well-documented. On their website, ‘Let's Encrypt’ keeps track of all ACME clients.
Here’s a list of the best options (n.b. most are for Linux):
lego. Lego is a one-file binary installation written in Go that supports many DNS providers;
acme.sh. Acme.sh is a simple shell script that can run in non-privileged mode and interact with more than 30 different DNS providers;
Caddy. Caddy is a full web server written in Go with built-in support for Let’s Encrypt.
‘Let’s Encrypt’ is just great, there are no other ways to put it. It’s a free, automated, and open certificate authority, run for the public’s benefit. It can be accessed via a variety of tools and services. The best part is, they really keep their motto close to heart:
“We give people the digital certificates they need in order to enable HTTPS (SSL/TLS) for websites, for free, in the most user-friendly way we can. We do this because we want to create a more secure and privacy-respecting Web for all.”
The Secure Sockets Layer (SSL) and the Transport Layer Security (TLS) cryptographic protocols have seen their share of flaws, like every other technology. In this article, we would like to list the most commonly-known vulnerabilities of these protocols. Most of them affect the outdated versions of these protocols (TLS 1.2 and below), although one major vulnerability was found that affects TLS 1.3.
POODLE
This cute name should not misguide you – it stands for Padding Oracle On Downgraded Legacy Encryption. Not that nice after all, right? It was published in October 2014 and it takes advantage of two peculiar facts. The first one is that some servers/clients still support SSL 3.0 for interoperability and compatibility with legacy systems. The second one is a vulnerability related to block padding that appears in SSL 3.0. Here is a link to that vulnerability on the NIST NVD database.
How does it work?
As mentioned before, this vulnerability comes from the Cipher Block Chaining (CBC) mode. Those block ciphers use blocks of a fixed length, so if the data in the last block is shorter than the block’s size, it is filled by padding. The server, of course, ignores such padding by default, it only checks whether the length is correct and verifies the Message Authentication Code (MAC) of the plaintext. In practice, this means that the server cannot verify if the content inside the padding has been altered in any way.
An attacker is able to modify padding data and then simply waits for the server’s response. Attackers can recover the contents byte-by-byte by watching server responses and altering the input. It usually takes no more than 256 attempts to reveal one byte of a cookie, which equates to a maximum of 4096 queries for a 16-bit cookie. Just by using automated scripts, the hacker may retrieve the plaintext char by char. Such a plaintext may be anything from a password to a cookie or a session. So, without even knowing the encryption method or key, a sniffer may easily decipher a block.
BEAST
The Browser Exploit Against SSL/TLS attacks was disclosed in September 2011. It affects browsers that support TLS 1.0, because this early version of the protocol has a vulnerability when it comes to the implementation of the above-mentioned CBC mode. Here’s a link to it in the NIST NVD database.
How does it work?
This kind of attack is usually client-side, so in order for it to succeed, an attacker should, in one way or another, have some control of the clients’ browser. After getting access to a browser, the attacker would typically use MITM to inject packets into the TLS stream. After such an injection, the only thing left is to guess the Initialization Vector (IV) – a random block of data that makes each message unique. This is used with the injected message and then simply compared with the results of the needed block.
CRIME
The Compression Ratio Info-leak Made Easy (CRIME) vulnerability affects TLS compression. The Client Hello message optionally uses the DEFLATE compression method, which was introduced to SSL/TLS to reduce bandwidth. The main method used by any compression algorithm is to replace repeated byte patterns with a pointer to the first instance of such sequences. As a result – the bigger the repeated sequences, the more effective such a compression is. You can visit this link to locate this vulnerability in the NIST NVD database.
How does it work?
Let’s imagine that a hacker is targeting cookies. He knows that the targeted website creates a cookie for each session named ‘ss’. The DEFLATE compression method replaces repeated bytes and our antagonist knows that. Therefore, he injects Cookie:adn=0 to the victim’s cookie. The server would, of course, append 0 to the compressed response, because Cookie:adn= has been already sent, so it is repeated.
After that, the only thing for an attacker to do is to inject different characters and then monitor the size of the response.
The injected character is contained in the cookie value if the answer is shorter than the first one, hence the compression. The response will be longer if the character is not in the cookie value. Using this strategy, an attacker can recreate the cookie value using the server's feedback.
By the way, the BREACH attack is very similar to CRIME, but it targets HTTP compression instead.
Heartbleed
Heartbleed was a major vulnerability discovered in the OpenSSL (1.0.1) library's heartbeat extension. This extension is used to maintain a connection so long as both participants are online. Here is its link on our beloved NIST NVD database.
How does it work?
The client sends the server a heartbeat message with a payload containing data and its size + padding. The server will respond with the same heartbeat request as the client.
The vulnerability comes from the fact that if the client sent a false data length, the server would respond with a heartbeat response containing not only the data received by the client but, because it needs to fill the length of the message, also with random data from its memory. A very unfortunate technical solution, isn’t it?
Leaking such unencrypted data may result in a disaster. It is well-documented that by using such a technique, an intruder may obtain a private key to the server. Moreover, if the attacker has the private key – well, that means he’s able to decrypt all the traffic to the server. I guess we don’t need to tell you why that’s no good, right?
The entire list of vulnerabilities may be found in this wonderful report by the Health Sector Cybercecurity Coordination Center. It not only lists all above-mentioned techniques in a very informative manner but also provides a very neat table of all ‘Known Threats to TLS/SLS’(pp. 24-26).
Instead of a long conclusion, let’s just look at the last page of that report:
The green cell of the chart explicitly states how to get rid of most known vulnerabilities. Indeed, if you’re not interested in trawling through the nooks and crannies of the Library of Alexandria’s floor on Cybersecurity, the best way to track existing SSL/TLS vulnerabilities is by visiting csrc.nist.gov once in a while. You might even consider making it your homepage.
Security, security, security… There is no way one can underestimate the importance of it when it comes to caring for private files and sensitive data. As long as the world of cybersecurity is privy to the constant conflict between hackers and programmers, fully protecting yourself and your business will forever be impossible. But, as we know, hackers aren’t always using state-of-the-art techniques. Often, they’re still getting in by guessing your username and password.
Most popular kinds of technology are under a constant barrage of hacking attempts, which is why it is so important to follow simple protocols to save yourself both time and money. One of such technologies is SSL/TLS. It is used on almost every web service, and even though it may seem straightforward to set up, there are many arcane configurations and design choices that need to be made to get it ‘just right’.
This guide will provide you with a short ‘checklist’ to keep in mind when setting up or maintaining SSL/TLS with a focus on security. All information is accurate and up to date as of December 2021 and is based on both our experience and other guides made on this topic.
Track all your certificates
First and foremost, you should check up on all existing certificates that are used by you and your organisation. This covers all information about them, such as their owners, locations, expiration dates, domains, cipher suites, and TLS versions.
If you don’t know about, or don’t track existing certificates as well as weak keys and cipher suites, you expose yourself to security breaches connected to expiring certificates.
An easy way to list all your certificates is to get them from your CA. This may not work if you used self-signed certificates, which require additional attention in terms of tracking/listing. The second way, which is typically quite effective, is to obtain certificates using network scanners. Hopefully, the enormous number of certifications that you were unaware of will not surprise you. Your certificate ‘inventory’ should focus on details such as OS and applications like Apache, just because your organization could be vulnerable to exploits that attack specific versions of things like OpenSSL (i.e., Heartbleed).
Web server configurations • O/S versions • Application versions • TLS versions • Cipher suites
Don’t use weak keys, cipher suites or hashes
Every certificate has a public key and a signature, both of which may be vulnerable if they were created with outdated technology. On public web servers, certificates with key lengths of less than 2048 bit or those that employ older hashing algorithms like MD5 or SHA-1 are no longer allowed. These may, however, be found on your internal services. If that's the case, you'll need to upgrade them.
The requirement to check TLS/SSL versions and cipher suites supported on your web servers is much more crucial than finding certificates with weak keys or hashes.
The following versions are outdated and must never be used: • SSL v2 • SSL v3 • TLS 1.0 • TLS 1.1 Instead, enable TLS 1.2 and TLS 1.3.
The following cipher suites are vulnerable, and must be disabled: • DES • 3DES • RC4 Instead, use modern ciphers like AES.
Install and renew all certificates on time
We recommend renewing a certificate at least 15 days before it expires to allow time for testing and reverting to the prior certificate if any problems arise.
Users should be notified when certificates expire, regardless of the mechanism you employ. Before expiration, the system should alert users automatically and at regular intervals (e.g., 90 days). Self-signed certificates should never have an expiration date of more than 30 days.
Never reuse key pairs for new certificates
By the same token, never reuse CSRs (Certificate Signing Requests) — this will automatically reuse the private key. Reusing keys leads to key pair vulnerability. Don’t be lazy when it comes to your security.
Review the CA that you use
Your certificates are only as trustworthy as the CA that issues them. All publicly trusted CAs are subject to rigorous third-party audits to maintain their position in major operating system and browser root certificate programs, but some are better at maintaining that status than others.
Use Forward Secrecy (FS)
Also known as perfect forward secrecy (PFS), FS assures that a compromised private key will not also compromise past session keys. To enable it, use at least TLS 1.2 and configure it to use the Elliptic Curve Diffie-Hellman (EDCHE) key exchange algorithm. The best practice here would be to use TLS 1.3 as it provides forward secrecy for all TLS sessions using the Ephemeral Diffie-Hellman key exchange protocol ‘out of the box’.
Use DNS CAA
DNS CAA is a standard that allows domain name owners to restrict which CAs can issue certificates for their domains. In September 2017, the CA/Browser Forum mandated CAA support as part of its certificate issuance standard baseline requirements. The surface area prone to attack is certainly shrunk with CAA in place, effectively making sites more secure. If CAs have an automated mechanism in place for certificate issuance, they should check for DNS CAA records to prevent certificates from being issued incorrectly. It is advised that you add a CAA record to your certificate to whitelist a CA. Add certificate authorities (CAs) that you trust.
Keep in mind that encryption is not an option.
Enforce encryption across your entire infrastructure — no 'bald spots' should remain. Leaving elements of your infrastructure unprotected is like forgetting to lock the door when you leave — it's not a good idea.
The practices that we’ve mentioned in this list are more about common sense, rather than knowledge acquired through the ultra-secret bureau. When it comes to security, you should always keep your infrastructure up-to-date. New vulnerabilities pop up every day, but still, we, humans, pose the biggest threat of all. In other words, human error has more to answer for than we might first believe. Because of this, double-check everything you do. Security protocols should be easy to follow not only by the person who creates them but also by everyone who interacts with your infrastructure — users and employees alike.
With such a checklist, it’s impossible to shine a light on each and every nook and cranny, so for those of you who want to ensure that you’re following all best practices, consider checking out this list.
Most web servers across the internet and intranets alike use SSL certificates to secure connections. These certificates are traditionally generated by OpenSSL – a software library containing an open-source implementation of the SSL and TLS protocols. Basically, we’re looking at a core library, providing us with a variety of cryptographic and utility functions. Because of its ease-of-use and, most importantly, because it’s open-source (so, free), it managed to make its way to the top, and now, it’s the industry standard.
OpenSSL is available for Windows, Linux and MacOS. So, before you get started, make sure that you have OpenSSL installed on your machine. Here’s a list of precompiled binaries for your convenience. But, to be honest, the OS doesn’t really matter here too much – the commands are going to be identical in our case.
In this tutorial, we’ll show you how easy it can be to generate self-signed certificates with OpenSSL.
Such a self-signed certificate is great if you want to use HTTPS (HTTP over TLS) to secure your Apache HTTP or Nginx web server, and you know that your certificate doesn’t need to be signed by a CA.
How should I use OpenSSL?
OpenSSL is all about its command lines. Below, we’ve put together a few common OpenSSL commands that regular users can fiddle about with to generate private keys. After each command, we’ll try to explain what that exact line of code does by breaking it down into its constituent parts. If you fancy studying all of the commands, take a look at this page.
How can I generate self-signed certificates?
Let’s start! First and foremost, we want to check whether we have OpenSSL installed. To do that, we need to run:
openssl version -a
If you get something like this, you’re on the correct path:
This code effectively specifies the SSL version that you have installed and some other details.
Now, the first important thing on our agenda is to generate a Public/Private keypair. To do this, we ought to punch in the following command:
openssl genrsa - out passwork.key 2048
genrsa – is the command to generate a keypair with the RSA algorithm;
-out passwork.key – this is the output key file name;
2048– key size. Make sure to double-check your requirements at this stage, because that value may change depending on your use case.
Now we have the file ‘passwork.key’ in a directory that we’ve specified. Once we’ve created a file we can, for example, extract the public key by running:
rsa – we ought to specify the algorithm that we used;
-in passwork.key – we take the existing keypair;
-pubout – here, we take only public key;
-out passwork_public.key – we’re exporting this as a file with name passwork_public.key.
Now we may proceed to creating a CSR – Certificate Signing Request. In a real production scenario, such a CSR is forwarded to the CA which signs it on your behalf, so you get a certificate. But for the sake of our tutorial, we’ll create a CSR and self-sign it.
req -new – here, we’re specifying that we want to create something new;
-key passwork.key – here, we’re specifying the key that we will use;
-out passwork.csr – here, we’re specifying the output file.
After pressing ‘Enter’ you’ll see something like this:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields, there will be a default value,
If you enter '.', the field will be left blank.
Enter the required data. For the purposes of our tutorial, we’ve entered the following fake values:
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:FL
Locality Name (eg, city) []:Tallahassee
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Passwork
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:*.passwork.com
Email Address []:[email protected]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
One of the most important fields is Common Name, which should match the server name or FQDN where the certificate is going to be used.
After all the above-mentioned steps, we’ll have our CSR file fully generated. In the real world, at this stage, we’d want to verify our CSR file, just so we’re not passing the wrong file to the CA. Also, it’s good practise to double-check whether the FQDN is correct.
As you can see, it lists crucial data that you provided when you answered questions related to the CSR. Check the values and if something is wrong – simply re-generate the CSR before you pass it on to the CA.
As we mentioned before, instead of passing our CSR to the CA, we’ll create a self-signed certificate. In order to do that, we ought to enter the following:
The ‘X509’ command is our multi purpose certificate utility;
-in passwork.csr represents our CSR;
-out passwork.crt is the name and file extension for our certificate;
-req signkey passwork.key – here, we’re specifying the keypair that we want to use to sign our certificate;
-days 30 – this is an expiration time interval for our certificate.
The passwork.crt certificate file has now been generated, so it’s ready to go! Pretty easy, right? Well, it gets a lot easier when we remember that we can generate a self-signed certificate by just entering:
Here, a temporary CSR is generated, so we don’t have to enter all the data manually.
Please bear in mind that in real-life situations, you should follow best practice when creating a private key, they can be easily generated and therefore compromised.
Conclusion
We’ve barely touched the functionalities within OpenSSL, but as you can see, it’s not as complicated as many people first think – that’s why it’s loved far and wide. If you’ve still got any unanswered and burning questions, feel free to check out the frequently-asked questions (FAQ) page on the OpenSSL project’s website. If that’s not enough and you’re really looking for a deep dive – we can’t recommend this free e-book highly enough.
The SSL/TLS protocol’s job is to ensure security through authentication. It was designed to encrypt data transmitted over open networks and, as a result, protect against interception and spoofing attacks. TLS also authenticates communicating parties, which leaves us with a pretty trusting environment. It goes without saying that security through authentication is essential for a successful business in the 21st century.
If we closely observe the way in which SSL works, it becomes very clear very fast, that to establish the ‘trusting environment’, SSL certificates need to be signed and validated by a trusted Certificate Authority (CA). Now, while everyone trusts the CA, by extension, they are able to trust those with its certification. Traditionally, organizations have used CAs to sign their SSL/TLS certificates, but with an influx of digital products, a huge amount of software being developed and tested in addition to an all-time data breach record, many companies are switching to self-signed certificates.
What is a Self-Signed SSL Certificate?
A self-signed certificate is a digital certificate that hasn’t been signed by a publicly trusted CA. Instead, it is issued and signed by the entity that is responsible for the software. This, on the one hand, makes deployment pretty frictionless, but on the other, it comes with additional risk, especially when poorly implemented.
Although they can be risky, self-signed certificates are incredibly widespread. These certificates are available with no associated costs and can be requested easily by anyone, which is fantastic for internal testing environments or web servers that are otherwise locked for external users. Moreover, such a certificate still uses the same encryption methods as other, paid SSL/TLS certificates – that’s a piece of very good news for organizations because nobody wants their data leaking. As long as the CA doesn’t require a certificate expiry date, a self-signed certificate may be issued once and used till the end of time. This is used, for example, when working on some secret projects or simply with internal data.
For many companies that use self-signed certificates, the biggest advantage is, of course, independence. All security infrastructure is encapsulated inside the internal network, so even if such a network isn’t connected to the web at all – it’ll still work as intended.
Although this looks very convenient on the surface, it is one of the major concerns when dealing with these types of certificates. Offline, they aren’t able to receive security updates in response to discovered vulnerabilities, nor meet the certificate agility which is essential to secure today's modern enterprise.
Another challenge that arises when dealing with self-signed certificates is that responsible departments often lack visibility over how many were issued, where they are used, by whom, and also how the private key is stored. It’s hard enough to keep track of certificates issued by different public and private CAs. It’s almost impossible to track all self-signed certificates without an additional request process.
Pros:
Fast and easy to issue;
Useful in test environments;
Flexibility;
Independence;
No expiration date.
Cons:
No security updates;
Can’t be easily revoked;
Lack of visibility and control.
Let’s imagine that our internal network has been breached. If we use self-signed certificates, there is literally no way of knowing if it, and private keys associated with it, have been compromised. Once compromised, such a certificate may be used to spoof identities and gain access to important data, especially considering the fact that, unlike CA-issued certificates, self-signed certificates cannot be revoked and, as we mentioned before, have no expiration date. You cannot simply ‘revoke’ a private key in such a situation.
So, why are self-signed certificates still in use? The simple answer is that it’s convenient. The routine manual process of submitting a certificate signing request (CSR) and waiting hours for verification is just horrible. To save time and frustration, it makes more sense to opt for self-signed certificates.
So the biggest question on self-signed certificates of any type is not how to issue them, but how to properly implement them inside an organisation. It’s like making sushi – the recipe is very simple, but the devil is in the details.
Some risks may be indirect – let’s imagine we’re looking to use a self-signed certificate to provide access to an employee portal. It will cause any default browser to alert the user with warnings. As these alerts can be ignored, many organisations tend to instruct their employees to do exactly that – ignore warnings. The safety of the internal portal is assured, so there is no direct harm, but, at the same time, employees ‘learn’ to ignore alerts and warnings the same way we all ignore ads on websites. Such practices make the organisation overall more vulnerable. The crux of the matter is that employees just don’t provide essential feedback on time if something goes very wrong.
To get the best out of self-issued certificates and mitigate the risks involved, we recommend using OpenSSL to issue certificates. It is de facto an industry standard. But, as mentioned before, this is not enough. Correct implementation is even more important than the tools used. After all, a top of the line DeWalt grinder is going to be useless if you’re using it to hammer in a nail. So, when implementing a self-signed certificate try to follow these best practices:
Limit the expiration period, it should be as short as possible. Never use certificates that don’t feature an expiry date.
Limit usage. Never create ‘universal certificates’ that open all doors at once.
Use a meaningful and informative ‘subject’ record. Everybody should understand what the certificate is being used for.
Make sure that the algorithm used for the signature is at least SHA256WITHRSA (which is the default in OpenSSL).
Most importantly, create a repeatable/scriptable process for issuing certificates and keys. OpenSSL is a de-facto standard command-line tool that can be used as the basis for this process.
Self-signed certificates are fast and easy to use, they are great for test environments, or when providing encrypted access to internal data. They provide independence and are free to use. That is why they are used across the board in so many companies. On the whole, there’s really no other way to do things right. But remember, SSL/TLS self-signed certificates are like fugu fish – it is delicious when cooked well, but you’ll drop dead if the chef’s on his lunch break.
Let's imagine that you decided to google ‘best sauces for Wagyu steak’. You went through several web pages, and then on page two of the search results, you get this notification from your Chrome browser:
Something went wrong, that's for sure. What happened? Should you proceed to the page without a private connection?
An IT expert would surely reply:
The error that you got here was probably because of an SSL/TLS handshake failure.
SSL? TLS?? Acronyms you’ve no doubt heard before, but ones that nevertheless evoke a dreary sense of confusion in the untrained mind. In this article, we’ll try to explain what SSL/TLS is, how it works and at the very least, you’ll understand what that lock icon on the address bar is.
Where did TLS originate?
TLS stands for Transport Layer Security, and it is right now the most common kind of Web PKI. It’s used not only to encrypt internet browsing but also for end-to-end connection (video calling, messaging, gaming, etc.).
As for now, we expect almost any kind of connection on the internet to be encrypted, and if something is encrypted, we get an alert similar to that seen in figure A. But that wasn't always the case. If you go back to the mid-90s – very little on the internet was encrypted. Maybe that was because fewer people were using the internet back then, or maybe it was because there weren’t credit-card details flying all over the place.
The history of TLS starts with Netscape. In 1994, it developed Secure Socket Layer 1 – the grandfather of modern TLS. Technically, it fits between TCP and HTTP as a security layer. While version 1 was used only internally and was full of bugs, very quickly, they fixed all the issues and released SSL 2. Then, Netscape patented it in 1995 with a view to stopping other people patenting it so they could release it for free. This was a very odd yet generous move, considering what the real-life patent practice was at that time.
In 1995, the world was introduced to Internet Explorer, a browser that used a rival technology called PCT (Private Communications Technology), which was very similar to SSL. But as with any rivalry – there could only be one winner. In November 1996, SSL 3 was released, which, of course, was an improvement on SSL 2. Right after that, the Internet Engineering Task Force created the Transport Layer Security Working Group to decide what the new standard for internet encryption would be. It was subsequently renamed from SSL to TLS (as far as we know, this was because Microsoft didn't want Netscape to have dibs on the name). It actually took three years for the group to release TLS 1. It was so similar to SSL 3 that people began to name it SSL 3.1. But over time, through updates, the security level rose massively; bugs were terminated, ciphers were improved, protocols were updated etc.
But, how does it all actually work?
TLS is a PKI protocol that exists between two parties. They effectively have to agree on certain things to identify each other as trustworthy. This process of identification is called a 'handshake'.
Let’s take a look at a TLS 1.2 handshake, as an example.
First, let's load any webpage, then, depending on your browser, press the lock icon near the web address text field. You’ll be shown certificate info and somewhere between the lines you'll find a string like this:
This is called a Cipher Suite. It’s a string-like representation of our 'handshake' recipe.
So, let’s go through some of the things shown here:
First, we have ECDHE (Elliptic-curve Diffie–Hellman), which is a key agreement protocol that allows two parties, each having an elliptic-curve public–private key pair, to establish a shared secret over an insecure channel. In layman’s terms, this is known as key exchange;
The RSA is our Public Key authentication mechanism (remember, we need a Public Key for any PKI);
AES256 refers to the cipher that we’re going to use (AES) and its' key size (256);
Lastly, SHA384 is effectively a building block that is used to perform hash functions.
Now, the trick is to exchange all that data in just several messages via our 'handshake'.
What exactly happens when we go to a new web page?
After we establish a TCP (Transmission Control Protocol) connection, we start our handshake. As always on the web, the user (Client) is requesting data from the Server – so he sends a 'Client Hello' message, which contains a bunch of data including:
The max TLS version that this Client can support so that both parties are able to 'speak the same language;
A random number to protect from replay attacks;
List of the cipher suites that the Client supports.
Assuming the Server is live, it responds with 'Server Hello', containing the Cipher Suite and TLS version it chose to connect with the Client + a random number. If the server can't choose a Suite or TLS version due to version incompatibility – it sends back a TLS Alert with a handshake failure. At this point, both the User and the Server know the communication protocol.
Keep in mind that the server is sending a Public key and a Certificate containing an RSA key. It’s important to know that the Certificate has an expiration date. You’ll understand why by the end of the article.
On top of that, the Server is sending a Server Key Exchange Message containing parameters for ECDHE with a public value. Very importantly, this Exchange Message also contains a digital signature (all previous messages are summarized using a hash function and signed using the private key of the Server). This signature is crucial because it provides proof that the Server is who they say they are.
When the Server is done transmitting all the above-mentioned messages, it sends a 'Server Hello Done' message. In Layman’s terms, that’s an ‘I’m done for the day, I’ll see you at the pub’ kind of message.
The Client, on the other hand, will look at the Certificate and verify it. After that, it will verify the signature using the Certificate (you can't have one without the other). If all goes well, the Client is assured of the Server’s authenticity and sends a Client Key Exchange Message. This message doesn't contain a Certificate but does contain a Pre-master Secret. It is then combined with the random numbers that were generated during the ‘Hello’ messages to produce a Master Secret. The Master Secret is going to be used for encryption at the next step.
It may seem very complicated now, but we’re almost done!
The next stage involves the Client sending the ‘Change Cipher Spec’ message, which basically says "I’ve got everything, so I can begin encryption – the next message I'll send you is going to be encrypted with parameters and keys".
After that, the Client proceeds to send the ‘Finished’ message containing a summary of all the messages so far encrypted. This helps to ensure that nobody fiddled with the messages; if the Server can't decrypt the message, it leaves the 'conversation'.
The Server will reply in the same way – with a Change Cipher Spec and a Finished message.
Handshaking is now done, parties can exchange HTTP requests/responses and load data. By the way, the only difference between HTTP and HTTPS is that the last one is secure – that's what the 'S' stands for there.
As you can see, it's incredibly difficult to crack this system open. However, that's exactly what we need to ensure security. Moreover, those two round trips that the data travels take no time at all, which is great; nobody wants their GitHub to take a month and a half to load up. By the way, the more advanced TLS 1.3 does all that in just one round trip!
Your connection is not private
When something goes wrong with TLS, you’ll see the warning that we demonstrated at the very beginning of this article. Usually, those are issues associated with the Certificate and its expiration date. That’s why your internet will refuse to work if you’ve messed around with the time and date settings on your device. But, if everything with the date and time is in check – never proceed to a website that triggers this warning, because most likely, between you and the server, somebody is parsing your private data.
What is Transport Layer Security (TLS) & how does it work?
Imagine you’re a system administrator at Home Depot. Just as you’re about to head home, you notice that your network has just authorized the connection of a new air-conditioner. Nothing too peculiar, right? The next morning, you wake up to find that terabytes of data including logins, passwords and customer credit card information have been transferred to hackers. Well, that’s exactly what happened in 2014, when a group of hackers, under the guise of an unassuming HVAC system, landed an attack that cost Home Depot over $17.5 million dollars, all over an incorrectly configured PKI. In this article, we’ll be conducting a crash course in PKI management.
So, what’s a PKI?
‘Public key infrastructure’ is a term that relates to a set of measures and policies that allow one to deploy and manage one of the most common forms of online encryption – public-key encryption. Apart from being a key-keeper for your browser, the PKI also secures a variety of different infrastructures, including internal communication within organizations, Internet of Things (IoT), peer to peer connection, and so on. There are two main types of PKIs:
• The Web PKI, also known as the “Internet PKI”, has been defined by RFC 5280 and refined by the CA/Browser Forum. It works by default with browsers and pretty much everything else that uses TLS (you probably use it every day).
• An Internal PKI – is the one you run for your own needs. We’re talking about encrypted local networks, data containers, enterprise IT applications or corporate endpoints like laptops and phones. Generally speaking, it can be used for anything that you want to identify.
At its core, PKI has a public cryptographic key that is used not to encrypt your data, but rather to authenticate the identities of the communicating parties. It’s like the bouncer outside an up-market club in Mayfair – you’re not getting in if you’re not on the list. However, without this ‘bouncer’, the concept of trustworthy online communication would be thrown to the wind.
So, how does it work?
PKI is built around two main concepts – keys and certificates. As with an Enigma machine, where the machine’s settings are used to encrypt a message (or establish a secure protocol), a key within a PKIisa long string of bits used to encrypt or decrypt encoded data. The main difference between the Enigma machine and a PKI is that with the latter, you have to somehow let your recipient know the settings used to encode the encrypted message.
The PKI gets its name because each party in a secured connection has two keys: public and private. A generic cipher protocol on the other hand, usually only uses a private one.
The public key is known to everyone and is used throughout the network to encode data, but the data cannot be accessed without a private key, which is used for decoding. These two keys are bound by complex mathematical functions which are difficult to reverse-engineer or crack by brute force. By the way, this principle is an epitome of asymmetrical cryptography.
So, this is how data is encrypted within a public key infrastructure. But let’s not forget that identity verification is just as important when dealing with PKIs – that’s where certificates come into play.
Digital Identity
PKI certificates are most commonly seen as digital passports containing lots of assigned data. One of the most important pieces of information in such a certificate relates to the public key: the certificate is the mechanism by which that key is shared – just like your Taxpayer Identification Number (TIN) or driver’s license, for instance.
But it’s not really valid unless it has been issued by some kind of entrusted authority. In our case, this is the certificate authority (CA). Here, there is an attestation from a trusted source that the entity is who they claim to be.
With this in mind, it becomes very easy to grasp what the PKI consists of:
• A certificate authority, which issues digital certificates, signs them with its public key and stores them in a repository for reference;
• A registration authority, which verifies the identities of those requesting digital certificates. A CA can act as its registration authority or can use a third party to do so;
• A certificate database that stores both the certificates, their metadata and, most importantly, their expiration dates;
• A certificate policy outlining the PKI's procedures (this is basically a set of instructions that allows others to judge how trustworthy a PKI is).
What is a PKI used for?
A PKI is great for securing web traffic – data flowing through the open internet can be easily intercepted and read if it isn't encrypted. Moreover, it can be difficult to trust a sender’s identity if there isn’t some kind of verification procedure in place.
But even though SSL/TLS certificates (that secure browsing activities) may demonstrate the most widespread implementation of PKI, the list doesn’t end there. PKI can also be used for:
• Digital signatures on software;
• Restricted access to enterprise intranets and VPNs;
• Password-free Wifi access based on device ownership;
• Email and data encryption procedures.
PKI use is taking off exponentially; even a microwave can connect to Instagram nowadays. This emerging world of IoT devices brings us new challenges and even devices seemingly existing in closed environments now require security. Taking the ‘evil air conditioner’ that we spoke about in the introduction as an example – gone are the days where we can take a piece of kit for face value. Some of the most compelling PKI use cases today centre around IoT. Auto manufacturers and medical device manufacturers are two prime examples of industries currently introducing PKI for IoT devices. Edison’s Electronic Health Check-up System would be a very good example here, but we’ll save that for a future deep-dive.
Is PKI a cure-all?
As with any technology – execution is sometimes more important than the design itself. A recent study by the Ponemon Institute surveyed nearly 603 IT and security professionals across 14 industries to understand the current state of PKI and digital certificate management practices. This study revealed widespread gaps and challenges, for example:
• 73% of security professionals admit that digital certificates still cause unplanned downtime and application outages;
• 71% of security professionals state that migration to the cloud demands significant changes to their PKI practices;
• 76% of security professionals say that failure to secure keys and certificates undermines the trust their organization relies upon to operate.
The biggest issue, however, is that most organizations lack the resources to support PKI. Moreover, only 38% of respondents claim they have the staff to properly maintain PKI. So for most organisations PKI maintenance becomes a burden rather than a cure-all.
To sum up, PKI is a silent guard that secures the privacy of ordinary online content consumers. However, in the hands of true professionals, it becomes a power tool that creates an encryption infrastructure that is almost infinitely scalable. It lives in your browser, your phone, your wifi access point, throughout the web and beyond. Most importantly, however, a correctly-configured PKI is the distance between your business and an imposter air conditioner that wants your hard-earned cash.
What is PKI? A Public Key Infrastructure definitive guide
