net/data/ssl/certificates/README

This directory contains various certificates for use with SSL-related
unit tests.

===== Real-world certificates that need manual updating
- google.binary.p7b
- google.chain.pem
- google.pem_cert.p7b
- google.pem_pkcs7.p7b
- google.pkcs7.p7b
- google.single.der
- google.single.pem
- thawte.single.pem : Certificates for testing parsing of different formats.

- googlenew.chain.pem : The refreshed Google certificate
     (valid until Sept 30 2013).

- mit.davidben.der : An expired MIT client certificate.

- foaf.me.chromium-test-cert.der : A client certificate for a FOAF.ME identity
     created for testing.

- www_us_army_mil_cert.der
- dod_ca_17_cert.der
- dod_root_ca_2_cert.der : 
     A certificate chain used for testing certificate imports

- unosoft_hu_cert : Certificate used by X509CertificateTest.UnoSoftCertParsing.

- google_diginotar.pem
- diginotar_public_ca_2025.pem : A certificate chain for the regression test
      of http://crbug.com/94673

- salesforce_com_test.pem
- verisign_intermediate_ca_2011.pem
- verisign_intermediate_ca_2016.pem : Certificates for testing two
     X509Certificate objects that contain the same server certificate but
     different intermediate CA certificates.  The two intermediate CA
     certificates actually represent the same intermediate CA but have
     different validity periods.

- cybertrust_gte_root.pem
- cybertrust_baltimore_root.pem
- cybertrust_omniroot_chain.pem
- cybertrust_baltimore_cross_certified_1.pem
- cybertrust_baltimore_cross_certified_2.pem
     These certificates are reflect a portion of the CyberTrust (Verizon
     Business) CA hierarchy. _gte_root.pem is a legacy 1024-bit root that is
     still widely supported, while _baltimore_root.pem reflects the newer
     2048-bit root. For clients that only support the GTE root, two versions
     of the Baltimore root were cross-signed by GTE, namely
     _cross_certified_[1,2].pem. _omniroot_chain.pem contains a certificate
     chain that was issued under the Baltimore root. Combined, these
     certificates can be used to test real-world cross-signing; in practice,
     they are used to test certain workarounds for OS X's chain building code.

- ndn.ca.crt: "New Dream Network Certificate Authority" root certificate.
     This is an X.509 v1 certificate that omits the version field. Used to
     test that the certificate version gets the default value v1.

- ct-test-embedded-cert.pem
- ct-test-embedded-with-intermediate-chain.pem
- ct-test-embedded-with-intermediate-preca-chain.pem
- ct-test-embedded-with-preca-chain.pem
     Test certificate chains for Certificate Transparency: Each of these
     files contains a leaf certificate as the first certificate, which has
     embedded SCTs, followed by the issuer certificates chain.
     All files are from the src/test/testdada directory in
     https://code.google.com/p/certificate-transparency/

- comodo.chain.pem : A certificate chain for www.comodo.com which should be
     recognised as EV. Expires Jun 20 2015.

- twitter-chain.pem : A certificate chain for twitter.com which should be
     valid. Expires May 9 2016.

===== Manually generated certificates
- client.p12 : A PKCS #12 file containing a client certificate and a private
     key created for testing.  The password is "12345".

- client-nokey.p12 : A PKCS #12 file containing a client certificate (the same
     as the one in client.p12) but no private key. The password is "12345".

- unittest.selfsigned.der : A self-signed certificate generated using private
     key in unittest.key.bin. The common name is "unittest".

- unittest.key.bin : private key stored unencrypted.

- unittest.originbound.der: A test origin-bound certificate for
     https://www.google.com:443.
- unittest.originbound.key.der: matching PrivateKeyInfo.

- x509_verify_results.chain.pem : A simple certificate chain used to test that
    the correctly ordered, filtered certificate chain is returned during
    verification, regardless of the order in which the intermediate/root CA
    certificates are provided.

- test_mail_google_com.pem : A certificate signed by the test CA for
    "mail.google.com". Because it is signed by that CA instead of the true CA
    for that host, it will fail the
    TransportSecurityState::IsChainOfPublicKeysPermitted test.

- multivalue_rdn.pem : A regression test for http://crbug.com/101009. A
     certificate with all of the AttributeTypeAndValues stored within a single
     RelativeDistinguishedName, rather than one AVA per RDN as normally seen.

- unescaped.pem : Regression test for http://crbug.com/102839. Contains
     characters such as '=' and '"' that would normally be escaped when
     converting a subject/issuer name to their stringized form.

- ocsp-test-root.pem : A root certificate for the code in
      net/tools/testserver/minica.py

- websocket_cacert.pem : The testing root CA for testing WebSocket client
     certificate authentication.
     This file is used in SSLUITest.TestWSSClientCert.

- websocket_client_cert.p12 : A PKCS #12 file containing a client certificate
     and a private key created for WebSocket testing. The password is "".
     This file is used in SSLUITest.TestWSSClientCert.

- no_subject_common_name_cert.pem: Used to test the function that generates a
  NSS certificate nickname for a user certificate. This certificate's Subject
  field doesn't have a common name.

- quic_intermediate.crt
- quic_test_ecc.example.com.crt
- quic_test.example.com.crt
- quic_root.crt
     These certificates are used by the ProofVerifier's unit tests of QUIC.

===== From net/data/ssl/scripts/generate-test-certs.sh
- expired_cert.pem
- ok_cert.pem
- root_ca_cert.pem
    These certificates are the common certificates used by the Python test
    server for simulating HTTPS connections.

- name_constraint_bad.pem
- name_constraint_good.pem
    Two certificates used to test the built-in ability to restrict a root to
    a particular namespace.

- sha256.pem: Used to test the handling of SHA-256 certs on Windows.

- spdy_pooling.pem : Used to test the handling of spdy IP connection pooling

- subjectAltName_sanity_check.pem : Used to test the handling of various types
     within the subjectAltName extension of a certificate.

- punycodetest.pem : A test self-signed server certificate with punycode name.
     The common name is "xn--wgv71a119e.com" (日本語.com)

- 10_year_validity.pem
- 11_year_validity.pem
- 39_months_after_2015_04.pem
- 40_months_after_2015_04.pem
- 60_months_after_2012_07.pem
- 61_months_after_2012_07.pem
- pre_br_validity_bad_121.pem
- pre_br_validity_bad_2020.pem
- pre_br_validity_ok.pem
- start_after_expiry.pem
    Certs to test that the maximum validity durations set by the CA/Browser
    Forum Baseline Requirements are enforced.

- reject_intranet_hosts.pem
   A certificate with a non-IANA delegated domain, which is rejected since a CA
   cannot validate the applicant controls that domain.

===== From net/data/ssl/scripts/generate-weak-test-chains.sh
- 2048-rsa-root.pem
- {768-rsa,1024-rsa,2048-rsa,prime256v1-ecdsa}-intermediate.pem
- {768-rsa,1024-rsa,2048-rsa,prime256v1-ecdsa}-ee-by-
      {768-rsa,1024-rsa,2048-rsa,prime256v1-ecdsa}-intermediate.pem
      Test certificates used to ensure that weak keys are detected and rejected

===== From net/data/ssl/scripts/generate-cross-signed-certs.sh
- cross-signed-leaf.pem
- cross-signed-root-md5.pem
- cross-signed-root-sha1.pem
     A certificate chain for regression testing http://crbug.com/108514

===== From net/data/ssl/scripts/generate-redundant-test-chains.sh
- redundant-validated-chain.pem
- redundant-server-chain.pem
- redundant-validated-chain-root.pem

     Two chains, A -> B -> C -> D and A -> B -> C2 (C and C2 share the same
     public key) to test that SSLInfo gets the reconstructed, re-ordered
     chain instead of the chain as served. See
     SSLClientSocketTest.VerifyReturnChainProperlyOrdered in
     net/socket/ssl_client_socket_unittest.cc. These chains are valid until
     26 Feb 2022 and are generated by
     net/data/ssl/scripts/generate-redundant-test-chains.sh.

===== From net/data/ssl/scripts/generate-policy-certs.sh
- explicit-policy-chain.pem
     A test certificate chain with requireExplicitPolicy field set on the
     intermediate, with SkipCerts=0. This is used for regression testing
     http://crbug.com/31497.

===== From net/data/ssl/scripts/generate-client-certificates.sh
- client_1.pem
- client_1.key
- client_1.pk8
- client_1_ca.pem
- client_2.pem
- client_2.key
- client_2.pk8
- client_2_ca.pem
     This is a set of files used to unit test SSL client certificate
     authentication.
     - client_1_ca.pem and client_2_ca.pem are the certificates of
       two distinct signing CAs.
     - client_1.pem and client_1.key correspond to the certificate and
       private key for a first certificate signed by client_1_ca.pem.
     - client_2.pem and client_2.key correspond to the certificate and
       private key for a second certificate signed by client_2_ca.pem.
     - each .pk8 file contains the same key as the corresponding .key file
       as PKCS#8 PrivateKeyInfo in DER encoding.

===== From net/data/ssl/scripts/generate-android-test-key.sh
- android-test-key-rsa.pem
- android-test-key-dsa.pem
- android-test-key-dsa-public.pem
- android-test-key-ecdsa.pem
- android-test-key-ecdsa-public.pem
     This is a set of test RSA/DSA/ECDSA keys used by the Android-specific
     unit test in net/android/keystore_unittest.c. They are used to verify
     that the OpenSSL-specific wrapper for platform PrivateKey objects
     works properly. See the generate-android-test-keys.sh script.

===== From net/data/ssl/scripts/generate-bad-eku-certs.sh
- eku-test-root.pem
- non-crit-codeSigning-chain.pem
- crit-codeSigning-chain.pem
     Two code-signing certificates (eKU: codeSigning; eKU: critical,
     codeSigning) which we use to test that clients are making sure that web
     server certs are checked for correct eKU fields (when an eKU field is
     present). Since codeSigning is not valid for web server auth, the checks
     should fail.

===== From net/data/ssl/scripts/generate-multi-root-test-chains.sh
- multi-root-chain1.pem
- multi-root-chain2.pem
     Two chains, A -> B -> C -> D and A -> B -> C2 -> E (C and C2 share the
     same public key) to test that certificate validation caching does not
     interfere with the chain_verify_callback used by CertVerifyProcChromeOS.
     See CertVerifyProcChromeOSTest.

===== From net/data/ssl/scripts/generate-duplicate-cn-certs.sh
- duplicate_cn_1.p12
- duplicate_cn_1.pem
- duplicate_cn_2.p12
- duplicate_cn_2.pem
     Two certificates from the same issuer that share the same common name,
     but have distinct subject names (namely, their O fields differ). NSS
     requires that certificates have unique nicknames if they do not share the
     same subject, and these certificates are used to test that the nickname
     generation algorithm generates unique nicknames.
     The .pem versions contain just the certs, while the .p12 versions contain
     both the cert and a private key, since there are multiple ways to import
     certificates into NSS.

===== From net/data/ssl/scripts/generate-aia-certs.sh
- aia-cert.pem
- aia-intermediate.der
- aia-root.pem
     A certificate chain which we use to ensure AIA fetching works correctly
     when using NSS to verify certificates (which uses our HTTP stack).
     aia-cert.pem has a caIssuers that points to "aia-test.invalid" as the URL
     containing the intermediate, which can be served via a URLRequestFilter.
     aia-intermediate.der is stored in DER form for convenience, since that is
     the form expected of certificates discovered via AIA.