X.509 Certificate Spurs

Monster oblo, mischievous, huge, gentleman and barking .

The set of technologies, which we habitually call SSL certificates, is a hefty iceberg, on top of which is a green lock to the left of the domain name in the address bar of your browser. The correct name is X.509 , which dates back to X.500 standard ITU-T DAP (Directory Access Protocol) . DAP did not take off, in the IETF it was considered inconvenient for use with all these OSI piles and invented LDAP instead, Lightweight DAP where the first letter means "lightweight". Those who had to tune, or worse, debug it can appreciate the irony to the fullest. The first letter of the abbreviation has never lied like this, except for SNMP.

By the way, what do LDAP, SNMP and X.509 have in common, besides the fact that they will not soon have to assemble stadiums of fans? They are united by ASN.1 - a meta-language for describing objects of antiquity. If these technologies were created now, XML, DTD or some other ML would be used. But at the time, standards were created by titans, for whom even SNMP was a simple matter.

Lexicon

The definition of X.509 certificates is in the ITU-T archive

 Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 

In order to thoroughly understand the notation and syntax, it is necessary to read the specs of the X.680 edition of 2008 , where there is a full description of ASN.1 . In terms of ASN.1, SEQUENCE means roughly the same as the struct in C. This can be confusing, because by semantics it should have been more likely to correspond to an array. And yet.

The X.690 standard defines the following rules for encoding data structures created in accordance with ASN.1 : BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). There is even XER (XML Encoding Rules), which I have never met in practice.

Yes, but why do we need X.509 certificates that deliver so much headache? The first and main function of X.509 certificates is to serve as a public key or public key storage (PKI). There are no complaints about this function, but the second one is not so simple.

The second function of X.509 certificates is that the bearer of this person is accepted by a person, or the program as the true owner of a certain digital asset: a domain name, a web site, etc. This turns out differently, not all certificates have high liquidity, if use financial terminology. Six months ago, Google threatened Simantec companies that they would no longer trust their certificates due to the fact that they issued as many as 30,000 faulty certificates.

Nomenclature of certificates

Let's look at what X.509 certificates are found in nature, if we consider them by location in food grade chain of trust.

• Root certificates are made in the root CA (certifying center) and have the following attributes: the issue and subject attributes are identical, and in the basicConstraints extension, the basicConstraints attribute is TRUE .
• Intermediate certificates - a vague term for certificates not signed by the root CA, which can form a chain of arbitrary length, starting from the root certificate and ending with the certificate of the final subject .
• End-entity certificates are final certificates in a chain that cannot sign other intermediate certificates with their private key.

By degree steepness expensive and reliable certificates are divided into 3 types: DV , OV and EV .

• DV - Domain Name Identity Certificates are easy to get. They are issued automatically and instantly after the certificate authority verifies that the applicant has the right to the domain name. Most often, it’s enough to open a message and follow the link. Naturally, the message will be sent to the mailbox with a domain name that should be verified.
• OV - not the domain name will be indicated in the certificate, but the name of the applicant’s organization itself. There is already no automatic speech dispensing, it will take several working days. The availability of the name of the applicant’s organization in the whois database is subject to verification. Can check the state registration and the validity of the phone number.
• EV - these certificates and get hard and they are not cheap. They can be identified by the name of the organization on the green lock on the address bar panel.
  
  

Rarely, who is ready to fork out for it. Offhand Yandex, StackOverflow.com and Habr can live without it. But those who are willing to make sacrifices for this must fulfill the following requirements:

1. Audit of legal, physical and operational activities of the organization.
2. You should make sure that the organization has the exclusive right to use the domain name.
3. You must make sure that the organization is authorized to issue a certificate of this type.

More details can be found in Hutrapes company TutHost . Also, the subject attribute of the X.509 EV certificate contains the jurisdictionOfIncorporationCountryName , businessCategory , and serialNumber .

By their properties, certificates are of the following types.

• Multi-Domain Certificates — A certificate can span multiple domain names using SAN , the subjectAltName attribute.
• Multi-host certificates - in cases where the subject attribute contains the CN=example.net record, while the DNS server can have several A / AAAA type, where one host name can correspond to several IP addresses. In this case, an X.509 certificate with the same hostname can be successfully restored on all such nodes.
• Certificates with the possibility of substitution, wildcard certificates - this is when the subject attribute contains the entry CN=*.example.net . It works the same way as in usual regular expressions, that is, it can be used on all sub-domains *.example.net .
• Qualified Certificates - RFC 3739 defines this term as referring to personal certificates, referring to the European Union's Electronic Signature Directive . In particular, RFC allows the subject attribute to contain values:
  
  • commonName (CN =),
  • givenName (GN =),
  • pseudonym =.
    
    Also subjectDirectoryAttributes includes the values:
  • dateOfBirth =,
  • placeOfBirth =,
  • gender =,
  • countryOfCitizenship =,
  • countryOfResidence =.

In Russia, the concept of a QS of a qualified certificate is defined by law in connection with access to state services. By slander Habrapost with the epic about the extraction of personal data from the COP.

Where do certificates come from?

More recently, there were only 2 ways to get the X.509 certificate, but times have changed and there is a third way since recently.

1. Create your own certificate and sign it yourself. Pros - it's free, cons - the certificate will be accepted only by you and, at best, by your organization.
   ')
   
2. Purchase a certificate in the CA. It will cost money depending on its various characteristics and capabilities mentioned above.
3. Get a free LetsEncrypt certificate, only the simplest DV certificates are available.

For the first scenario, a couple of commands are enough and in order not to get up 2 times, we will create a certificate with an algorithm of elliptic curves . The first step is to create a private key. It is believed that encryption with an elliptic curve algorithm provides greater exhaust , if measured in CPU cycles, or bytes of the key length. ECC support is not uniquely defined in TLS <1.2.

 openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pem 

Next, it creates a CSR - certificate signing request.

 openssl req -new -sha256 -key private.key -out server.csr -days 730 

And sign up.

 openssl x509 -req -sha256 -days 365 -in server.csr -signkey private.key -out public.crt 

The result can be viewed with the command:

 openssl x509 -text -noout -in public.crt 

Openssl has a huge number of options and commands. Man page is not very useful, the directory is more convenient to use as follows:

 openssl -help openssl x509 -help openssl s_client -help 

Exactly the same can be done using the java utility keytool .

 keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048 

A series of questions follows to remember what the owner and issuer fields are.

 What is your first and last name? What is the name of your organizational unit? What is the name of your organization? What is the name of your City or Locality? What is the name of your State or Province? What is the two-letter country code for this unit? Is CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU correct? 

We convert the keychain from proprietary format to PKCS12.

 keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12 

We look at the result:

 Alias name: selfsigned Creation date: 20.01.2018 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU Issuer: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU Serial number: 1f170cb9 Valid from: Sat Jan 20 18:33:42 MSK 2018 until: Tue Jan 15 18:33:42 MSK 2019 Certificate fingerprints: MD5: B3:E9:92:87:13:71:2D:36:60:AD:B5:1F:24:16:51:05 SHA1: 26:08:39:19:31:53:C5:43:1E:ED:2E:78:36:43:54:9B:EA:D4:EF:9A SHA256: FD:42:C9:6D:F6:2A:F1:A3:BC:24:EA:34:DC:12:02:69:86:39:F1:FC:1B:64:07:FD:E1:02:57:64:D1:55:02:3D Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 30 95 58 E3 9E 76 1D FB 92 44 9D 95 47 94 E4 97 0.X..v...D..G... 0010: C8 1E F1 92 .... ] ] 

The value of ObjectId: 2.5.29.14 corresponds to the definition of ASN.1, according to RFC 3280 it is always non-critical . Similarly, you can find out the meaning and possible values ​​of other ObjectId that are present in the X.509 certificate.

 subjectKeyIdentifier EXTENSION ::= { SYNTAX SubjectKeyIdentifier IDENTIFIED BY id-ce-subjectKeyIdentifier } SubjectKeyIdentifier ::= KeyIdentifier 

Leadtsrypt

You can get the X.509 LetsEncrypt certificate for free and you don’t even need to go to the website, you only need to install certbot .

 sudo emerge -av certbot # Gentoo sudo apt-get install certbot -t stretch-backports #Debian sudo dnf install certbot #Fedora sudo certbot certonly --standalone -d example.com -d www.example.com 

Scenario number 1 - find the next in a bunch

Linking Certificates - Combine multiple X.509 certificates into one file, most often in PEM format. The bundle is transmitted over the network at the time of the SSL / TLS handshake protocol.

The juice starts when dealing with a bunch of certificates, ak a certificate chain . Often looking through the noodles in the jks not easy to understand how to find the parent certificate when there is a scattering of new and old certificates for several domain names.

Consider a bunch of certificates *.novell.com . The Authority Key Identifier (AKI) extension must match the Subject Key Identifier (SKI) senior in the bundle.

 Certificate Authority Key Identifier Size: 20 Bytes / 160 Bits 51 68 ff 90 af 02 07 75 3c cc d9 65 64 62 a2 12 b8 59 72 3b 

That's right, the DigiCert SKI certificate has the same meaning.

 Certificate Subject Key ID Size: 20 Bytes / 160 Bits 51 68 ff 90 af 02 07 75 3c cc d9 65 64 62 a2 12 b8 59 72 3b 

For root certificate AKI = SKI , as well as isCa=true

 Certificate Basic Constraints Critical Is a Certificate Authority 

Scenario number 2 - use subjectAltnName, Luke

Imagine you have a web server application: wiki, wordpress or cacti. You set up access via https , purchased or generated and signed the certificate yourself. Everything should be fine, but there is still no green lock. The browser suspects that the certificate was prepared by the wrong bees, due to the fact that the FQDN server and the hostname specified in the address bar do not match. So sometimes it happens that the DNS server points to mars.domain.com , and the web server is configured to venus.domain.com .

If the administrator, by virtue of perfectionism, needs besides the drive, checkers are also needed - a coveted green lock, then you need to redo the X.509 certificate, defining the subjectAltName in it.

Open the openssl.cnf file and add the following lines in the req section.

 [ alternate_names ] DNS.1 = example.com DNS.2 = www.example.com DNS.3 = mail.example.com DNS.4 = ftp.example.com 

Further, in the [ v3_ca ] section, specify.

 subjectAltName = @alternate_names 

And then everything as usual, create a private key and sign the certificate.

 openssl genrsa -out private.key 3072 openssl req -new -x509 -key private.key -sha256 -out certificate.pem -days 730 

Used materials

• Survival guides - TLS / SSL and SSL (X.509) Certificates
• Parse the x.509 certificate
• Creating ECDSA SSL Certificates in 3 Easy Steps
• Implementing SSL / TLS Using Cryptography and PKI
• Certificate Chaining Engine - how it works
• How can I generate a self-signed certificate with SubjectAltName using OpenSSL? [closed]