Difference between revisions of "X.509 Certificate"

From MgmtWiki
Jump to: navigation, search
(→‎Solutions)
(→‎References)
 
(84 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Name or Meme==
 
==Full Name or Meme==
−
A structure defined by the CCITT (now ITU) that binds a [[Subject]] name to a public key and a set of [[Attribute]]s.
+
A structure defined by the CCITT (now ITU-T) that binds a [[Subject]] name to a public key and a set of [[Attribute]]s.
  
 
==Context==
 
==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.
 +
** and RFC 3279 titled ''Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile''
 +
* A [https://datatracker.ietf.org/doc/html/draft-klasen-ldap-x509certificate-schema-02 draft LDAPv3 Schema for X.509 Certificate] was issued in 2003-03-03.
 +
* The IETF issued RFC 5280 in 2008-05 for V3 called ''Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile''
 +
* New rules was written in RFC 5912 (2010-06) '' New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)'' and updated in RFC 6960 (2013-06) for ''Online Certificate Status Protocol (OCSP)''
  
 
==Problems==
 
==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 DN 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.
 +
===Privacy===
 +
* One of the early uses of [[X.509 Certificate]]s was in Privacy Enhanced Mail ([[PEM]]) which also tried to enable non-repudiation. The result is that an [[X.509 Certificate]] was required and all of the information in that certificate became public knowledge. When that was finally realized the PEM effort was abandoned.
 +
* Studies have shown<ref>Charlie Osborn ''SSL certificate research highlights pitfalls for company data, competition'' (2021-11-05) ZD net https://www.zdnet.com/article/ssl-certificate-research-highlights-pitfalls-for-company-data/</ref> that may certificates contain information that aid an attacker to discover facts that the company may want to keep private. The people that order the certificates are often not trained in risk assessment which results in leaked information.
  
 
==Solutions==
 
==Solutions==
−
*The content of a [[Web Site]] certification is reasonably well defined<ref>DigiCert. ''What extensions and details are included in a SSL certificate?'' https://knowledge.digicert.com/solution/SO18140.html</ref>
+
*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<ref>DigiCert. ''What extensions and details are included in a SSL certificate?'' https://knowledge.digicert.com/solution/SO18140.html</ref> 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 [[Public Key Infrastructure|PKI]] to establish encrypted security of internet connections over HTTP (the web). There existing standards for more secure certificates, DV Certs and [[EV Cert]]s 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 Certificate]]s===
 +
 
 +
The major operating systems, like Windows, have been notoriously bad at the [[User Experience]] associated with [[X.509 Certificate]]s. 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 Certificate]]s, 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 Card]]s, and for [[Web Site]]s.
 +
 
 +
====Web Site Trust====
 +
*[[Web Site Security]] in early 2019 was dependent on the use of [[X.509 Certificate]]s. The rest of the section will discuss the best way to support that, the [[Web Site Security]] page discusses alternate means for [[Web Platform Identifier]]s that are currently under development.
 +
* Each browser (or other [[User Agent]] is supplied with a list or acceptable root Certificate Authorities. Some security conscious organizations either supply their own list of accept certificates or ask users to add some of their own to the default list. Fore example the [https://www.cnss.gov/CNSS/help/DoD_Root_Cert_Help_Final.pdf DoD requests users to add their certificate to others on the user's browser.]
 +
* 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 [https://windowsserveressentials.com/2013/02/06/manually-creating-a-certificate-request-windows-server-essentials-sbs/ Manually creating a Certificate Request Windows Server 2012] is still the simplest description available and is summarized here below.
 +
#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.
 +
#Under the section on IIS like the link for Server Certificates
 +
#In the right-hand panel select "Create a Certificate Request" - note that this will create a private key if one is not existent
 +
##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.
 +
##The rest of the fields should have real values in them, although the Organization unit (OU) has little value for an SSL cert.
 +
##The next page will allow you to select a key length. While 1024 bits is typically sufficient, it is recommended to choose 2048 bits to make the certificate "future proof".
 +
##Store the resultant Certificate Request (CSR) as a file with a name which could be something like "example.com.csr".
 +
##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.
 +
#Go to your favorite SSL [[Certificate Authority]] with the CSR to get a certificate
 +
#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 and plunge into it.
 +
##For AWS you must have the command line interface. Here is how to [https://docs.aws.amazon.com/cli/latest/userguide/install-windows.html Install the AWS CLI on Windows]
 +
##Here are the instructions on [https://aboutssl.org/install-ssl-certificate-amazon-web-services-aws/ 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.
 +
##Note that AWS has the incomprehensible policy of requiring private keys to be uploaded unencrypted, once you have decrypted the private key ([https://stackoverflow.com/questions/991758/how-to-get-pem-file-from-key-and-crt-files 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 Certificate]]s for creating a chain of trust since they were first put into use for the secure transport of a holder's [[Identifier]]s. 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 [https://blog.cloudflare.com/introducing-cfssl/ Cloudflare app cfssl] for this example of how a json version of the cert used for thrustregisty.org used to be:
 +
<pre>
 +
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"
 +
}</pre>
 +
 
 +
===Schema===
 +
 
 +
<pre>
 +
{
 +
    "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
 +
}</pre>
  
 
==References==
 
==References==
 +
 +
 +
[[Category: Glossary]]
 +
[[Category: Trust]]
 +
[[Category: Identifier]]

Latest revision as of 11:48, 30 July 2022

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.
    • and RFC 3279 titled Algorithms and Identifiers for the 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.
  • The IETF issued RFC 5280 in 2008-05 for V3 called Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
  • New rules was written in RFC 5912 (2010-06) New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) and updated in RFC 6960 (2013-06) for Online Certificate Status Protocol (OCSP)

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

Privacy

  • One of the early uses of X.509 Certificates was in Privacy Enhanced Mail (PEM) which also tried to enable non-repudiation. The result is that an X.509 Certificate was required and all of the information in that certificate became public knowledge. When that was finally realized the PEM effort was abandoned.
  • Studies have shown[1] that may certificates contain information that aid an attacker to discover facts that the company may want to keep private. The people that order the certificates are often not trained in risk assessment which results in leaked information.

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[2] 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

  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 existent
    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 choose 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 and 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. ↑ Charlie Osborn SSL certificate research highlights pitfalls for company data, competition (2021-11-05) ZD net https://www.zdnet.com/article/ssl-certificate-research-highlights-pitfalls-for-company-data/
  2. ↑ DigiCert. What extensions and details are included in a SSL certificate? https://knowledge.digicert.com/solution/SO18140.html
Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=X.509_Certificate&oldid=15289"