Questo contenuto non è disponibile nella lingua selezionata.

5.8. Using Certificate Transparency


Certificate System provides a basic version of Certificate Transparency (CT) V1 support (rfc 6962). It has the capability of issuing certificates with embedded Signed Certificate Time stamps (SCTs) from any trusted log where each deployment site choses to have its root CA cert included. You can also configure the system to support multiple CT logs. A minimum of one trusted CT log is required for this feature to work.

Important

It is the responsibility of the deployment site to establish its trust relationship with a trusted CT log server.
For more information on how to configure Certificate Transparency, see the Configuring Certificate Transparency section in the Red Hat Certificate System Planning, Installation, and Deployment Guide.

5.8.1. Testing Certificate Transparency

As example on how to test a CT setup, the following procedure describes an actual test against Google CT test logs. A more comprehensive test procedure would involve setting up a TLS server and test for the inclusion of its certs from its specified CT logs. However, the following serves as a quick test that checks for inclusion of the SCT extension once a certificate has been issued.
The test procedure consists in generating and submitting a Certificate Signing Request (CSR), in order to verify its SCT extension using openssl. The test configuration in the CS.cfg file is as follows:
ca.certTransparency.mode=enabled
ca.certTransparency.log.1.enable=true
ca.certTransparency.log.1.pubKey=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEw8i8S7qiGEs9NXv0ZJFh6uuOm<snip>
ca.certTransparency.log.1.url=http://ct.googleapis.com:80/testtube/
ca.certTransparency.log.1.version=1
ca.certTransparency.log.2.enable=true
ca.certTransparency.log.2.pubKey=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEKATl2B3SAbxyzGOfNRB+AytNTG<snip>
ca.certTransparency.log.2.url=http://ct.googleapis.com:80/logs/crucible/
ca.certTransparency.log.2.version=1
ca.certTransparency.log.3.enable=false
ca.certTransparency.log.3.pubKey=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEiKfWtuoWCPMEzSKySjMjXpo38W<snip>
ca.certTransparency.log.3.url=http://ct.googleapis.com:80/logs/solera2020/
ca.certTransparency.log.3.version=1
ca.certTransparency.log.num=3
  1. First, generate a CSR, e.g:
    # PKCS10Client -d . -p passwd -l 2048 -n "cn=user.test.domain.com,OU=user-TEST,O=TestDomain" -o pkcs10-TLS.req
  2. Next, submit the CSR to an enrollment profile depending on the CT mode defined by the ca.certTransparency.mode parameter in CS.cfg:
    • if the parameter is set to enabled, use any enrollment profile
    • if the parameter is set to perProfile, use one of the CT profiles: e.g. caServerCertWithSCT
  3. Copy the issued b64 cert into a file, e.g. .ct1.pem.
  4. Convert the pem to binary:
    #  AtoB ct1.pem ct1.bin
  5. Display the DER certificate content:
    #  openssl x509 -noout -text -inform der -in ct1.bin
  6. Observe that the SCT extension is present, e.g:
    								CT Precertificate SCTs:
    								 Signed Certificate Timestamp:
    										 Version   : v1 (0x0)
    										 Log ID    : B0:CC:83:E5:A5:F9:7D:6B:AF:7C:09:CC:28:49:04:87:
    																 2A:C7:E8:8B:13:2C:63:50:B7:C6:FD:26:E1:6C:6C:77
    										 Timestamp : Jun 11 23:07:14.146 2020 GMT
    										 Extensions: none
    										 Signature : ecdsa-with-SHA256
    																 30:44:02:20:6E:E7:DC:D6:6B:A6:43:E3:BB:8E:1D:28:
    																 63:C6:6B:03:43:4E:7A:90:0F:D6:2B:E8:ED:55:1D:5F:
    																 86:0C:5A:CE:02:20:53:EB:75:FA:75:54:9C:9F:D3:7A:
    																 D4:E7:C6:6C:9B:33:2A:75:D8:AB:DE:7D:B9:FA:2B:19:
    																 56:22:BB:EF:19:AD
    								 Signed Certificate Timestamp:
    										 Version   : v1 (0x0)
    										 Log ID    : C3:BF:03:A7:E1:CA:88:41:C6:07:BA:E3:FF:42:70:FC:
    																 A5:EC:45:B1:86:EB:BE:4E:2C:F3:FC:77:86:30:F5:F6
    										 Timestamp : Jun 11 23:07:14.516 2020 GMT
    										 Extensions: none
    										 Signature : ecdsa-with-SHA256
    																 30:44:02:20:4A:C9:4D:EF:64:02:A7:69:FF:34:4E:41:
    																 F4:87:E1:6D:67:B9:07:14:E6:01:47:C2:0A:72:88:7A:
    																 A9:C3:9C:90:02:20:31:26:15:75:60:1E:E2:C0:A3:C2:
    																 ED:CF:22:A0:3B:A4:10:86:D1:C1:A3:7F:68:CC:1A:DD:
    																 6A:5E:10:B2:F1:8F
    
    Alternatively, verify the SCT by running an asn1 dump:
    #  openssl asn1parse -i -inform der -in ct1.bin
    and observe the hex dump, e.g:
      740:d=4  hl=4 l= 258 cons:     SEQUENCE
    		744:d=5  hl=2 l=  10 prim:      OBJECT            :CT Precertificate SCTs
    		756:d=5  hl=3 l= 243 prim:      OCTET STRING      [HEX DUMP]:0481F000EE007500B0CC83E5A5F97D6B<snip>
Red Hat logoGithubRedditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita ilBlog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

© 2024 Red Hat, Inc.