SSL certificates: everyone, everyone, and let no one leave offended
As previously reported at GeekTimes, EFF, with the support of Mozilla, Cisco, Akamai, IdenTrust, and researchers from the University of Michigan (University of Michigan) created a new Non-Commercial Certificate Authority Let's Encrypt [1] . The goal of the project is to accelerate the transition of the World Wide Web from HTTP to HTTPS.
As stated in [2] , despite the fact that HTTP has received a huge spread (which is a sign of a successful protocol), its disadvantage is insecurity (openness of transmitted data) by-design. Whenever a user connects to the site via HTTP, he is subject to a number of potential problems, such as hijacking accounts, intercepting traffic, tracking government and commercial organizations, embedding malicious code (scripts) in the code pages, censorship.
Researchers note that HTTPS, although not a panacea, solves these problems, so the transition to its widespread use is an important task.
The project is scheduled to launch in the summer (June?) Of 2015. Let's Encrypt will automatically issue free certificates for any site that requests them. Planned. that switching from HTTP to HTTPS using this service will be done by submitting just one command or pressing a button (cloud technologies — automation to the masses).
')
It should be noted here that the most significant problems with the deployment of HTTPS, researchers consider the complexity, bureaucracy and cost of certificates required for HTTPS to work. Many users have repeatedly encountered warnings and errors resulting from problems with certificates.
The procedure for obtaining a certificate is bureaucratic, complicated and is the leading reason that websites continue to use HTTP instead of HTTPS.
One of the goals of the Let's Encrypt project is to eliminate unnecessary links and automate the process, which, according to informal measurements by developers, will reduce the encryption setting time from 1-3 hours to 20-30 seconds.
The project is based on a number of innovative approaches and technologies for managing secure automatic domain verification and issuing certificates. For this purpose, it is planned to use the ACME protocol developed for these purposes between the web server and the CA. Verification will, among other things, use the SSL Observatory (EFF), scans.io (MichU), Certificate Transparency (Google) services.
For the operation of the new CA, a new non-profit organization Internet Security Research Group (ISRG) is being created.
Anyone who has configured HTTPS from scratch knows that obtaining a certificate is not the easiest procedure (going, for someone already worked out and quite understandable). The creators of the project suggest [3] that with the launch of the project it will be enough to execute a couple of commands:
Then example.com becomes available.
The script (set of scripts) Let's Encrypt will do the following:
All this - without confirmation by e-mail, editing configuration files, and for free.
For the operation of the system, an agent is implemented on your server that implements the ACME (Automatic Certificate Management Environment) protocol.
The process of proving domain ownership is as follows [4] :
After the agent is authorized, it can request, renew, or revoke certificates for its domain (s). Relevant messages must be signed with an authorized key pair.
To obtain a certificate for the domain, the agent generates a Certificate Signing Request (CSR) PKCS # 10 with a request to Let's Encrypt CA to issue a certificate for example.com with the specified public key. As usual, the CSR is signed by the private key corresponding to the public key in the request. Additionally, the CSR is signed by an authorized domain key in order to confirm the CA legitimacy of the request.
Upon receipt of the request, CA verifies both signatures. If they are correct, it issues a certificate for example.com with the public key from the CSR and returns it to the agent.
Other procedures (update, revocation) work in a similar way.
The ACME protocol is discussed in detail in [5] . Certificates in X.509 PKI (Public Key Infrastructure, public key infrastructure) are used for various purposes, the most significant of which is domain name authentication. Thus, the Certificate Authority (CA) PKI is “trusted” to ensure that the certificate requester (applicant) party legitimately represents the domain names listed in the certificate. Currently, verification is performed through a set of private indirect mechanisms. The creators of ACME set out a way to interact directly and automatically verify and issue certificates.
In established practice [5] , obtaining a certificate consists of a series of mostly manual operations:
The main idea for ACME was to obtain certificates for Web sites (HTTPS [7] ). In this case, each server is responsible for one or more domains, and the process (described above) is designed to verify this compliance.
For various purposes it is possible to use different types of certificates [8] :
Of these, DV is probably the most popular (here, the price, the minimum complexity and sufficiency are the main factors). It is important that for confirmation at the DV level, all checks can be performed by the CA automatically, without operator intervention. This is a key feature of the ACME solution — issuing DV certificates comparable in complexity to issuing a self-signed certificate.
To demonstrate that the server (applicant) is actually authorized to send messages on behalf of a certain domain, the ACME CA will request the solution of the following types of problem sets (this implies that the permission of example.com to the “controllable” agent node must be via A or AAAA record):
The client (agent) is exchanged with the ACME server (CA) using the HTTPS protocol with the exchange of JSON messages. Each ACME message is a dictionary (dictionary), with a mandatory field of type (type), which determines the composition of the remaining fields of the message. All messages are sent to the common HTTPS URI wired into the client. The client, in general, behaves like a browser, sending requests by the POST method, following the redirects (statuses 301, 302). Answers usually come with status 200, error information is encoded in JSON responses with the type “error”.
The creators of the protocol, in my opinion, wisely foreseen the type of response "defer", which allows you to force the client to wait a specified time interval before re-request. Since the service is likely to be quite popular, then the opportunity to ask the client to wait if the server, for example, is overloaded and the request is queued, will allow the creators of Let's encrypt (and future services based on this protocol) to reduce infrastructure costs.
When processing a CSR (sent as base-64 encoded; DER [10] ), the server checks the validity of the fields before issuing the certificate. It is assumed that the CA will discard the entity names (Subject Alt Name) from the certificate being issued, for which the requesting client (applicant) does not have authorization. In response, the JSON containing the applicant's certificate includes the certificate itself (base-64 encoded; DER) and the chain of parent certificates in the form of the base64 array, DER, in the order required for the TLS handshake by [11] , i.e. so that the first certificate in the array confirms the certificate of the applicant, the second certificate of the array confirms the first certificate of the array (each subsequent certificate confirms the immediate predecessor; the root certificate may be discarded because it is assumed that it already exists on the client).
The client part is written in Python, there is a preview on GitHub: https://github.com/letsencrypt/lets-encrypt-preview and he already knows how to configure Apache (there is a stub under nginx)
The server part is written on JS, GitHub: https://github.com/letsencrypt/node-acme
In the project wiki, you can find information on how to try all this on your server.
Illustrations from letsencrypt.org .
What is the point?
As stated in [2] , despite the fact that HTTP has received a huge spread (which is a sign of a successful protocol), its disadvantage is insecurity (openness of transmitted data) by-design. Whenever a user connects to the site via HTTP, he is subject to a number of potential problems, such as hijacking accounts, intercepting traffic, tracking government and commercial organizations, embedding malicious code (scripts) in the code pages, censorship.
Researchers note that HTTPS, although not a panacea, solves these problems, so the transition to its widespread use is an important task.
The project is scheduled to launch in the summer (June?) Of 2015. Let's Encrypt will automatically issue free certificates for any site that requests them. Planned. that switching from HTTP to HTTPS using this service will be done by submitting just one command or pressing a button (cloud technologies — automation to the masses).
')
It should be noted here that the most significant problems with the deployment of HTTPS, researchers consider the complexity, bureaucracy and cost of certificates required for HTTPS to work. Many users have repeatedly encountered warnings and errors resulting from problems with certificates.
The procedure for obtaining a certificate is bureaucratic, complicated and is the leading reason that websites continue to use HTTP instead of HTTPS.
One of the goals of the Let's Encrypt project is to eliminate unnecessary links and automate the process, which, according to informal measurements by developers, will reduce the encryption setting time from 1-3 hours to 20-30 seconds.
The project is based on a number of innovative approaches and technologies for managing secure automatic domain verification and issuing certificates. For this purpose, it is planned to use the ACME protocol developed for these purposes between the web server and the CA. Verification will, among other things, use the SSL Observatory (EFF), scans.io (MichU), Certificate Transparency (Google) services.
For the operation of the new CA, a new non-profit organization Internet Security Research Group (ISRG) is being created.
How will this work?
Anyone who has configured HTTPS from scratch knows that obtaining a certificate is not the easiest procedure (going, for someone already worked out and quite understandable). The creators of the project suggest [3] that with the launch of the project it will be enough to execute a couple of commands:
$ sudo apt-get install lets-encrypt$ lets-encrypt example.comThen example.com becomes available.
The script (set of scripts) Let's Encrypt will do the following:
- Automatically "prove" the server CA Let's Encrypt that you control the site (domain)
- Receive a certificate that will be trusted by browsers and installs it on your server, making the necessary configuration changes
- Will track the expiration time (expiration) of the certificate and request its renewal.
- Will help with the revocation of the certificate if necessary
All this - without confirmation by e-mail, editing configuration files, and for free.
What is under the hood?
For the operation of the system, an agent is implemented on your server that implements the ACME (Automatic Certificate Management Environment) protocol.
The process of proving domain ownership is as follows [4] :
- An agent on the server sends a request to Let's Encrypt CA with an indication of the domain that needs to be confirmed (example.com)
- The CA evaluates the domain and generates one or more challenge sets, the solution of which by the agent proves that the domain belongs. Such tasks are divided into two types:
- create DNS records for the subdomain example.com
- creating a resource accessible via HTTP at a known URI in example.com
- In addition to domain validation tasks, a temporary attribute (data object) is generated, which the agent on the server signs with his private key to prove ownership of the attribute.
- The agent performs one of the sets of tasks and the signing of the attribute and notifies the CA that it is ready for verification.
- CA begins verification by verifying electronic digital signature (EDS) and the availability of files / subdomains
- If the EDS is correct and the problem is solved correctly, the CA considers that the agent identified by some public key is authorized to manage certificates for the example.com domain. The key pair used by the agent becomes the "authorized key pair" for example.com.
After the agent is authorized, it can request, renew, or revoke certificates for its domain (s). Relevant messages must be signed with an authorized key pair.
To obtain a certificate for the domain, the agent generates a Certificate Signing Request (CSR) PKCS # 10 with a request to Let's Encrypt CA to issue a certificate for example.com with the specified public key. As usual, the CSR is signed by the private key corresponding to the public key in the request. Additionally, the CSR is signed by an authorized domain key in order to confirm the CA legitimacy of the request.
Upon receipt of the request, CA verifies both signatures. If they are correct, it issues a certificate for example.com with the public key from the CSR and returns it to the agent.
Other procedures (update, revocation) work in a similar way.
Learn a little more?
Problem
The ACME protocol is discussed in detail in [5] . Certificates in X.509 PKI (Public Key Infrastructure, public key infrastructure) are used for various purposes, the most significant of which is domain name authentication. Thus, the Certificate Authority (CA) PKI is “trusted” to ensure that the certificate requester (applicant) party legitimately represents the domain names listed in the certificate. Currently, verification is performed through a set of private indirect mechanisms. The creators of ACME set out a way to interact directly and automatically verify and issue certificates.
In established practice [5] , obtaining a certificate consists of a series of mostly manual operations:
- Generate PKCS request # 10 [6] - CSR
- Copy-Paste CSR on CA page
- Prove domain ownership using one of the following methods:
- Place the issued CA object (URI challenge) in the specified location on the server
- Place the line issued by CA (DNS challenge) in the specified DNS node corresponding to the confirmed domain
- Get a message from CA (email challenge) to a (theoretically) domain-controlled email address and enter the code on the CA page
- Download the issued certificate and install it on the server.
The main idea for ACME was to obtain certificates for Web sites (HTTPS [7] ). In this case, each server is responsible for one or more domains, and the process (described above) is designed to verify this compliance.
For various purposes it is possible to use different types of certificates [8] :
- Extended Validation (EV) - CA checks the applicability of the domain name and the characteristics of the organization (there are documents in order, the domain belongs to the organization, the organization requested the issuance of a certificate; more details in [9] )
- Organization Validation (OV) - CA verifies the legitimacy of the application of the domain name and the organization’s domain name
- Domain Validation (DV) - CA checks the applicability of the domain user’s use
Of these, DV is probably the most popular (here, the price, the minimum complexity and sufficiency are the main factors). It is important that for confirmation at the DV level, all checks can be performed by the CA automatically, without operator intervention. This is a key feature of the ACME solution — issuing DV certificates comparable in complexity to issuing a self-signed certificate.
How is domain ownership confirmed?
To demonstrate that the server (applicant) is actually authorized to send messages on behalf of a certain domain, the ACME CA will request the solution of the following types of problem sets (this implies that the permission of example.com to the “controllable” agent node must be via A or AAAA record):
- Creating a domain in the DNS TXT-record type _acme-challenge.example.com. containing some coolrandomealfanumerictoken issued by the server
- place the file so that it is available at the URI example.com/magnificientalfanumerictoken , GET by CA
- place the file so that it is accessible by the URI example.com/yetanothertoken , for which the agent in a hurry raises the HTTPS; GET verification from CA
- raise HTTPS (using self-signed certificate) and accept a TLS connection from CA. The certificate is formed in this way. to contain (in subjectAltName) the checked domain and the domain of the form <Z> .acme.invalid ", where Z = SHA-256 (R || S), (R is a random value reported by the server during the exchange process; S is a random value reported by customer)
- the list may be further expanded, for example, email, DNSSEC, WHOIS is planned
How is the client-server exchange?
The client (agent) is exchanged with the ACME server (CA) using the HTTPS protocol with the exchange of JSON messages. Each ACME message is a dictionary (dictionary), with a mandatory field of type (type), which determines the composition of the remaining fields of the message. All messages are sent to the common HTTPS URI wired into the client. The client, in general, behaves like a browser, sending requests by the POST method, following the redirects (statuses 301, 302). Answers usually come with status 200, error information is encoded in JSON responses with the type “error”.
The creators of the protocol, in my opinion, wisely foreseen the type of response "defer", which allows you to force the client to wait a specified time interval before re-request. Since the service is likely to be quite popular, then the opportunity to ask the client to wait if the server, for example, is overloaded and the request is queued, will allow the creators of Let's encrypt (and future services based on this protocol) to reduce infrastructure costs.
When processing a CSR (sent as base-64 encoded; DER [10] ), the server checks the validity of the fields before issuing the certificate. It is assumed that the CA will discard the entity names (Subject Alt Name) from the certificate being issued, for which the requesting client (applicant) does not have authorization. In response, the JSON containing the applicant's certificate includes the certificate itself (base-64 encoded; DER) and the chain of parent certificates in the form of the base64 array, DER, in the order required for the TLS handshake by [11] , i.e. so that the first certificate in the array confirms the certificate of the applicant, the second certificate of the array confirms the first certificate of the array (each subsequent certificate confirms the immediate predecessor; the root certificate may be discarded because it is assumed that it already exists on the client).
Show me your code!
Disclaimer
(You need to note here, just in case, that the code is not mine, I'm just sympathetic)
The client part is written in Python, there is a preview on GitHub: https://github.com/letsencrypt/lets-encrypt-preview and he already knows how to configure Apache (there is a stub under nginx)
The server part is written on JS, GitHub: https://github.com/letsencrypt/node-acme
In the project wiki, you can find information on how to try all this on your server.
Sources and references
- https://letsencrypt.org/
- https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web
- https://letsencrypt.org/howitworks/
- letsencrypt.org/howitworks/technology
- https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md
- http://www.ietf.org/rfc/rfc2314.txt
- http://tools.ietf.org/html/rfc2818
- https://www.globalsign.com/ssl-information-center/types-of-ssl-certificate.html
- https://cabforum.org/ev-code-signing-certificate-guidelines/
- https://en.wikipedia.org/wiki/X.690#DER_encoding
- http://tools.ietf.org/html/rfc5246
Illustrations from letsencrypt.org .
Source: https://habr.com/ru/post/244037/
All Articles