Difference between revisions of "X.509 Certificate"

Revision as of 10:46, 23 August 2021

Full Name or Meme

A structure defined by the CCITT (now ITU-T) that binds a Subject name to a public key and a set of Attributes.

Context

• Up until the 1970's the Postal and Telecommunications Agencies of the world governments just knew that they were responsible for assigning names and numbers to everything on the planet.
• At that time only a few of the world governments, like the US, had placed the responsibilities for such naming and numbering in private hands.
• Still in the US AT&T acted with the impunity of a government agency, until they were challenged in court by companies like MCI.
• With all of the arrogance of a government body, the ITU's Committee on Communications and International Telephone and Telegraph (CCITT), decided to specify the structure of email and the corresponding security.
• The goal was the electronic equivalent of the existing white pages and yellow pages of the ubiquitous telephone directories.
• The IETF issued RFC 3280 in 2002-04 with definitions of the fields present in the certificate and the certificate revocation lists.
• The IETF issued RFC 5280 in 2008-05 for V3 called Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
• A draft LDAPv3 Schema for X.509 Certificate was issued in 2003-03-03.

Problems

• The result was an exceeding ugly encoding of everything the CCITT touched, most of which has faded into history, except the X.509 certificate structure and naming in LDAP.
• The security at the time was based on the paradigm at the time - the credit card industry and the card revocation lists, which were updated every few weeks and needed to be checked by every merchant for every transaction.

Solutions

• At least now the certificates can be checked online (OCSP) and no longer require certificate revocation lists (CRL), although the specification still exists.
• The content of a Web Site certificate is reasonably well defined^[1] which makes them still useful for that purpose.
• The content of a personal certificate has not been so well accepted except for highly paranoid organizations (like the US DoD) who continue to issue smart cards with personal certificates.
• They can be used in venues such as a digital assertion of the existence of some credential, like the ability to prescribe drugs, or to sign a digital document as an agent of some real-world entity.
• The security of the standard X.509 certificate works well enough with PKI to establish encrypted security of internet connections over HTTP (the web). There existing standards for more secure certificates, DV Certs and EV Certs that provide more Assurance of the real world Identity of the Entity that hosts the web site, but there are many who believe that we sill can, and should, do a much better of Assurance.
• The web, meanwhile, is shifting to a new paradigm, the Json Web Token.

Installing X.509 Certificates

The major operating systems, like Windows, have been notoriously bad at the User Experience associated with X.509 Certificates. Although the tortured syntax and incomprehensible semantics of the certificates cannot help, it is at least conceivable that a better User Experience might have enabled a better acceptance of the X.509 Certificates, it is now not conceivable that they could be resurrected as a useful means of identification of people, which was the intent when they were invented. So this section will just deal with the few places where they are still encouraged, for devices, like Smart Cards, and for Web Sites.

Web Site Trust

Web Site Security in early 2019 was dependent on the use of X.509 Certificates. The rest of the section will discuss the best way to support that, the Web Site Security page discusses alternate means for Web Platform Identifiers that are currently under development.

On Windows the tools for creating a secure web site are fragmented due their original purpose, which was simply to enable certificates on Windows Active Directory Domains. The web page at Manually creating a Certificate Request Windows Server 2012 is still the simplest description available and is summarized here below.

1. The simplest place to start is on a Windows Server running IIS as the client is only able to create certificates that have been profiled in a Windows AD domain.
2. Under the section on IIS like the link for Server Certificates
3. In the right hand panel select "Create a Certificate Request" - note that this will create a private key if one is not existant
   1. The common name will be the web site address. If you use a "*.name.com" here you will be creating a "wild Card" certificate which can cost significantly more.
   2. The rest of the fields should have real values in them, although the Organization unit (OU) has little value for an SSL cert.
   3. The next page will allow you to select a key length. While 1024 bits is typically sufficient, it is recommended to chose 2048 bits to make the certificate "future proof".
   4. Store the resultant Certificate Request (CSR) as a file with a name which could be something like "example.com.csr".
   5. If you want to check the results of the CSR, open the MMC console, select file-add snap-in and add certificate, click ok and select local machine, then navigate to the "REQUEST" section. Clicking on the certificate and selecting details on the dialog box will give you all of the fields present in the CSR.
4. Go to your favorite SSL Certificate Authority with the CSR to get a certificate
5. Now that you have an SSL cert, it needs to be installed on the web site together with the private key. This is far more complex than it should be. Just steel yourself for the pain an plunge into it.
   1. For AWS you must have the command line interface. Here is how to Install the AWS CLI on Windows
   2. Here are the instructions on How to Install SSL Certificate on Amazon Web Services (AWS). The biggest part of the pain is collecting all of the components in the right format and assembling them into a file in the exact format and specific sequence that AWS requires. AWS tries to con you into using their service to avoid the pain now, but if you ever try to move away from AWS the pain will be even worse.
   3. Note that AWS has the incomprehensible policy of requiring private keys to be uploaded unencrypted, once you have decrypted the private key (for help see this site), assembled and uploaded the PEM file, ensure that all of the files containing the unencrypted key are deleted.

Smart Card Trust

Smart Card security has depended on X.509 Certificates for creating a chain of trust since they were first put into use for the secure transport of a holder's Identifiers. That situation is not likely to change. The advantages of using a Smart Card for Identifier proofing is that the card provides a Trusted Execution Environment where the Private Key Component can be fully protected from disclosure. The disadvantages are that a smart card reader needs to be installed on your local computer and that the mutual authentication User Experience is unnecessarily convoluted.

Cert to json

This uses the Cloudflare app cfssl for this example of how a json version of the cert used for thrustregisty.org used to be:

These commands are entered into a bash shell.
cfssl certinfo -cert cert.pem
{
  "subject": {
    "common_name": "trustregistry.org",
    "names": [
      "trustregistry.org"
    ]
  },
  "issuer": {
    "common_name": "R3",
    "country": "US",
    "organization": "Let's Encrypt",
    "names": [
      "US",
      "Let's Encrypt",
      "R3"
    ]
  },
  "serial_number": "316337519544732095201990243517622590769115",
  "sans": [
    "*.trustregistry.org",
    "trustregistry.org"
  ],
  "not_before": "2021-06-09T01:19:57Z",
  "not_after": "2021-09-07T01:19:57Z",
  "sigalg": "SHA256WithRSA",
  "authority_key_id": "14:2E:B3:17:B7:58:56:CB:AE:50:9:40:E6:1F:AF:9D:8B:14:C2:C6",
  "subject_key_id": "47:BE:85:6D:2:68:AE:C4:F3:E2:50:74:E0:98:79:57:23:67:E6:48",
  "pem": "-----BEGIN CERTIFICATE-----\nMIIFPTCCBCWgAwIBAgISA6Gh5iR21HrLK8PGKI4OagfbMA0GCSqGSIb3DQEBCwUA\nMDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD\nEwJSMzAeFw0yMTA2MDkwMTE5NTdaFw0yMTA5MDcwMTE5NTdaMBwxGjAYBgNVBAMT\nEXRydXN0cmVnaXN0cnkub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC\nAQEArrz40qjtjiktKtS8alm5f/VNtq7ZUi2Vm+thm8drkfAOW/sR0W3u8s7DbF44\nNy7VWSq33SzyJrSYzH+guVzYCxSFsBYj6c8yJeMaC1Vjjku/LBTW7EqLQ/L/HFkp\nPnOUxbUrr4nrCrpUC9ndKg0jpnfMbE6R7goyM8qJD/bXQj3iaj6Ztt7dqTx8RlbK\n/mtfsSE4jyF3eRvcODeBnenVOFXnErO3MmZcQfaI+PadMFCXdjooeet7zYrINlX7\nuUBbrChi2eE+FqfGaKzMFrN3rtH7+I9n3ylgRik8fDGthrHcTzmwuykm5SuIa/sV\n96tg50DY70WWqOvdoADSChBe5QIDAQABo4ICYTCCAl0wDgYDVR0PAQH/BAQDAgWg\nMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0G\nA1UdDgQWBBRHvoVtAmiuxPPiUHTgmHlXI2fmSDAfBgNVHSMEGDAWgBQULrMXt1hW\ny65QCUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6\nLy9yMy5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iu\nb3JnLzAxBgNVHREEKjAoghMqLnRydXN0cmVnaXN0cnkub3JnghF0cnVzdHJlZ2lz\ndHJ5Lm9yZzBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYG\nCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQQGCisGAQQB\n1nkCBAIEgfUEgfIA8AB1AFzcQ5L+5qtFRLFemtRW5hA3+9X6R9yhc5SyXub2xw7K\nAAABee6RteMAAAQDAEYwRAIgAqjCY7CDk1owtD1tSW54+3HRuKwRPiwbvc7ga3ry\n0ycCIBrxg4GtuETfO2133KZ2/c+2vhLi55oawhtbagRjLhjZAHcA9lyUL9F3MCIU\nVBgIMJRWjuNNExkzv98MLyALzE7xZOMAAAF57pG15AAABAMASDBGAiEAhweOyZgp\nPRJ5McnG7gjKc6uMTyZGMj7I3qq4maItQjUCIQCxp+9pgIYtSGO/TUXVdrVzL8/R\nTKNl1gRfTtftlKJkYzANBgkqhkiG9w0BAQsFAAOCAQEARf9Dkj1uL4Gj2RW01GS8\nTrJBQOOPS74t1gGXx5UpL16GNUuDeCCGyGccBswgTZUEXfK10/lZseVCZRNXKUk7\nIOg3sWox/n75tzLmWFVGxRA4FRgjhha/waC9mUK9Qqr9fuX1VKmflIvUgda1C1jI\nRdbeiPmjPPmtZ9aD0hbIujQiiCmqps1pbgExYI0wd8ilsXxZxQjS/u129O8yfhLy\nMo8tb0z+T67Gamcbvc09X4J9yQ3CgoqM6kShtIKV9P6Pnef3q7hXpuXo207ixYjn\nle1fFfdN9Vb8WvPlyutEtKYfKaYE1+EOU7vyuqaTGZJHHeToKuNCBK1uunN0auv4\n/g==\n-----END CERTIFICATE-----\n"
}

Schema

{
    "tbscertificate":  {
        "_type": SEQUENCE
        "version": INTEGER,
        "subject": Name,
        "issuer": Name,
        "serial_number": INTEGER+1,
        "sans": [
             "*.trustregistry.org",
             "trustregistry.org"
         }
    ],
  "not_before": "2021-06-09T01:19:57Z",
  "not_after": "2021-09-07T01:19:57Z",
  "sigalg": "SHA256WithRSA",
  "authority_key_id": "14:2E:B3:17:B7:58:56:CB:AE:50:9:40:E6:1F:AF:9D:8B:14:C2:C6",
  "subject_key_id": "47:BE:85:6D:2:68:AE:C4:F3:E2:50:74:E0:98:79:57:23:67:E6:48",
  "pem": String
}

References

1. ↑ DigiCert. What extensions and details are included in a SSL certificate? https://knowledge.digicert.com/solution/SO18140.html