search

DataONEorg / ca

DataONE Certificate Authority
1 stars 1 forks source link

Cross Signing Experiment #1

Closed artntek closed 9 months ago

artntek commented 1 year ago

Writing up from a slack convo with @datadavev and @mbjones

As part of Metacat's move to k8s we want to "cross-sign" our DataONE intermediate CA cert, because the current version is signed with a sha1 ca root, which is not supported by modern servers when verifying client certs.

For context, see:

It seems like the following should result in a usable system:

  1. Create a new CA Root cert, self signed using sha265
  2. Create a new Intermediate cert:
    • containing the same Subject DN as the current intermediate
    • containing the same Public Key as the current intermediate, and
    • signed using the new sha265 CA Root

I already have a client cert kindly issued by @datadavev from the sha1 DataONE Test Intermediate CA (signed by the sha1 DataONE Test Root CA), so a good experiment might be to create a new sha256 test root cert and use it to sign a new sha256 intermediate with the constraints listed above. I could then try this out on a metacat k8s install, and test with my existing client cert.

Open to feedback and discussions, if any of this seems off-base. It's all new to me :-)

artntek commented 1 year ago

for posterity, my musings from slack:

If we create a new sha-256 intermediate cert, but make sure it contains the same public key (and, of course, the same Subject DN) that was embedded in the older (weak) cert , then I'm thinking we shouldn't need to update any client certs. (but I'm not sure, so this is why we're experimenting).

AFAICT, the only information about the intermediate cert that is contained in the client cert is:

  • the Issuer DN
  • the Authority Key Identifier (AKID)

...so when verifying the client cert, the server looks up the intermediate based on this info, then uses the intermediate's public key to decrypt the signature on the client cert.

The only way a "weak" root CA comes into the picture is when the server then follows the chain up from the intermediate. If we've ditched the old intermediate and replaced it with the new one, then this verification will always work

artntek commented 1 year ago

I tried this with locally self-signed certs:

Based on Matt's original README file in the dataone software/tools/trunk/ca/ repo

A. FAILING TEST FIRST

  1. create and self-sign sha1 root cert (1-RootCA)
  2. create and sign sha1 intermediate cert (1-intermediate)
  3. create and sign sha256 client (node) cert (1-NodeN)
  4. test on cmd line - should verify OK:
    • sha1 root - sha1 intermediate - orig client - YES
  5. install & test on nginx - should fail:
    • sha1 root - sha1 intermediate - orig client

YES - fails:

    curl -X GET \
             -H "Accept: text/xml" \
             "${ENDPOINT}/object/urn:uuid:9b67aa51-00ae-4ae1-9cdb-e19e2659aed2" \
              --insecure --cert 1-NodeN.pem --key NodeN.key
    <html>
    <head><title>400 The SSL certificate error</title></head>
    <body>
    <center><h1>400 Bad Request</h1></center>
    <center>The SSL certificate error</center>
    <hr><center>nginx</center>
    </body>
    </html>

B. SUCCESS WITH SHA-256 CERTS

  1. create and self-sign sha256 root cert
  2. create sha256 intermediate CSR and sign cert with SAME:
    • Subject DN - DC = org, DC = dataone, CN = DataONE Test Intermediate CA
    • PubKey (ie use same Private Key as input to CSR). This step differs from Matt's script/readme by using -key for existing key that was used for generating old (weak) intermediate CSR instead of -newkey option, thus generating same public key in CSR:
openssl req -new -key ../../SHA1/DataONEProdCA/DataONEProdCA.key -out req/DataONEProdCA.csr -config ../DataONERootCA/rootca-openssl.cnf
  1. Using same client cert as above (signed with original weak chain)...
  2. test on cmd line - should verify OK:
    • sha256 root - sha256 intermediate - orig client - YES
  3. install & test on nginx - should work:
    • new Chain file (sha256 root + sha256 intermediate) - orig client

YES - succeeds:

curl -X GET  -H "Accept: text/xml"    "${ENDPOINT}/object/urn:uuid:9b67aa51-00ae-4ae1-9cdb-e19e2659aed2"  --insecure --cert 1-NodeN.pem --key NodeN.key
<eml:eml xmlns:eml="https://eml.ecoinformatics.org/eml-2.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:stmml="http://www.xml-cml.org/schema/stmml-1.1" xsi:schemaLocation="https://eml.ecoinformatics.org/eml-2.2.0 https://eml.ecoinformatics.org/eml-2.2.0/eml.xsd" packageId="urn:uuid:9b67aa51-00ae-4ae1-9cdb-e19e2659aed2" system="knb"><dataset><title>2021-08-10 private readably by CN=MB and CN=NODEID</title><creator id="8412381786459959"><individualName><surName>2021-08-10 private readably by CN=MB</surName></individualName><userId directory="https://orcid.org">https://orcid.org/0000-0002-1472-913X</userId></creator><abstract><para>2021-08-10 private readably by CN=MB and CN=NODEID</para></abstract><intellectualRights><para>This work is dedicated to the public domain under the Creative Commons Universal 1.0 Public Domain Dedication. To view a copy of this dedication, visit https://creativecommons.org/publicdomain/zero/1.0/.</para></intellectualRights><contact id="2888412193250720"><individualName><surName>2021-08-10 private readably by CN=MB</surName></individualName><userId directory="https://orcid.org">[https://orcid.org/0000-0002-1472-913X</userId></contact></dataset></eml:eml>%](https://orcid.org/0000-0002-1472-913X%3C/userId%3E%3C/contact%3E%3C/dataset%3E%3C/eml:eml%3E%25)

Note the new chain file did not need to contain the old intermediate or root in order to work

mbjones commented 11 months ago

@artntek and I got much of this working on the test Int CA, but ran into a problem where the certificate was missing its DC attributes in the subject. After a lot of sleuthing, I figured out that this is due to the Policy Format, which explicitly removes any part of the Subject DN which is not explicitly mentioned in the policy format. Here's the documentation from man openssl-ca:

POLICY FORMAT The policy section consists of a set of variables corresponding to certificate DN fields. If the value is "match" then the field value must match the same field in the CA certificate. If the value is "supplied" then it must be present. If the value is "optional" then it may be present. Any fields not mentioned in the policy section are silently deleted, unless the -preserveDN option is set but this can be regarded more of a quirk than intended behaviour.

Turns out that we had commented out the dc = match part of the policy, which meant that all DC parts of the subject are dropped. I tried adding it back in, and got the error the the dc name didn't exist. However, I noted that the long name for that field is domainComponent, and if I use that in the policy (domainComponent = match), then suddenly things are starting to work more and I don't get the same errors. Instead, I now get the following error:

The domainComponent field does not exist in the CA certificate, the 'policy' is misconfigured

What this means is that the domainComponent fields in the intermediate cert we are trying to sign does not exist in the root CA certificate (which is true, because when we created the root CA cert, it was also missing its DC fields). To test this theory, I tried changing the policy to domainComponent = supplied, which means CSRs must have the DC attributes, but they don't have to match the root CA values. Suddenly, this works without error, and the new certificate is created with the proper subject DN with its DC attributes.

So, next step is to go back and recreate the root CA cert with the correctly set subject with DC fields in the subject, and then recreate the intermediate CA as well. Trying that now...

mbjones commented 11 months ago

🎉 It lives! 🎉

After regenerating the root CA with the new policy match, then generating the intermediate CA worked great. Here's the output of the signing attempt, showing the policy match succeeding:

❯ openssl ca -out ../DataONETest256IntCA/certs/DataONETest256IntCA.pem -days 36500 \
    -keyfile /Volumes/DATAONE/DataONETest256CA.key -config ./openssl.cnf \
    -extensions v3_ca  -verbose -infiles ../DataONETest256IntCA/req/DataONETest256IntCA.csr
Using configuration from ./openssl.cnf
Enter pass phrase for /Volumes/DATAONE/DataONETest256CA.key:
V   21231016061054Z     3B671707F25159B017C97630CB45962083DD285E    unknown /DC=org/DC=dataone/CN=DataONE Test 256 CA
1 entries loaded from the database
generating index
message digest is sha256
policy is policy_match
next serial number is 3B671707F25159B017C97630CB45962083DD285F
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject:
            domainComponent           = org
            domainComponent           = dataone
            commonName                = DataONE Test Intermediate CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:c9:f7:9b:6e:e4:13:8c:31:d4:57:4e:b5:08:87:
                    09:70:01:c2:15:e5:0f:c2:53:19:d5:1a:d4:84:4e:
                    46:aa:5a:ce:63:76:6d:cb:ff:69:61:bf:14:f8:7d:
                    e6:76:40:05:55:be:6a:75:e2:1d:6b:62:83:8d:24:
                    1e:2d:66:7b:0f:a7:62:27:85:5d:48:f2:e3:4e:27:
                    2c:e7:66:b2:9f:90:2f:e9:f9:8b:6c:4d:ae:9c:8e:
                    04:ac:e9:72:17:b1:56:53:21:6f:e0:e4:64:9e:ce:
                    41:43:8a:39:1b:b3:59:e2:18:34:03:5c:11:28:ac:
                    bc:c3:88:d2:5e:7a:cb:4b:d3:82:7d:d1:99:70:56:
                    fa:89:01:7c:48:3a:d0:da:ac:e1:6e:2d:1e:4c:fc:
                    bd:c9:26:3c:38:db:48:f3:30:d9:1c:51:5f:26:1f:
                    4f:9b:61:5a:66:d7:f3:44:7b:82:04:88:53:61:e3:
                    e4:0a:6b:a6:65:06:e0:30:ee:a2:d4:23:2b:6c:f9:
                    87:3b:92:2f:65:23:2b:ef:a2:c3:96:89:60:37:22:
                    96:74:b2:ba:a5:fc:5d:48:8f:be:4a:3c:d9:88:89:
                    0a:70:46:fc:48:f0:11:63:3a:46:42:32:05:2e:50:
                    bc:30:bd:b4:9c:1f:86:74:c3:e0:e7:d3:5a:e1:63:
                    0f:44:df:b2:67:01:a2:bb:5a:f7:18:88:d9:15:66:
                    05:37:14:22:b9:3e:f3:45:bf:8c:5a:ba:2a:9d:2a:
                    ce:9e:db:05:b7:54:20:a9:17:f7:73:fb:ad:de:1b:
                    e2:1e:d0:3b:3a:08:78:4a:65:df:62:ab:8e:4f:63:
                    2a:a8:5f:3a:bf:0b:b2:b6:fe:ff:de:e5:61:6e:f2:
                    7a:80:f4:14:09:5c:c6:8b:a7:07:43:24:91:4b:19:
                    4f:62:22:d6:7b:fc:3b:e4:32:40:80:48:70:9d:b2:
                    91:4b:08:e0:df:97:d9:30:78:73:48:f7:68:22:d0:
                    1e:dd:b9:51:b0:66:91:4e:cc:a1:17:e6:da:ad:d9:
                    54:fe:a9:cf:2c:c7:8e:23:6e:2e:cb:01:27:54:e3:
                    e2:fe:9e:71:27:19:59:95:52:68:53:e4:79:66:5e:
                    28:87:fc:cf:6e:83:62:87:d1:b0:b2:c5:11:9b:35:
                    d8:1c:a2:92:26:26:e5:89:94:8d:6e:3e:54:0f:76:
                    74:10:47:06:7c:c4:a7:4f:f5:e0:dc:5e:42:f8:7f:
                    94:4f:f9:f9:b1:29:29:a7:f7:a1:b8:0b:42:c2:10:
                    6a:cb:94:cd:57:d4:44:f6:a3:97:64:2c:19:34:25:
                    12:34:08:83:73:2e:01:36:72:3c:e4:04:bf:a3:90:
                    2a:1e:13
                Exponent: 65537 (0x10001)
        Attributes:
            (none)
            Requested Extensions:
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        5d:0e:f5:23:98:87:42:01:19:81:03:b1:80:1a:8a:1c:07:cb:
        30:a9:e0:bf:46:11:6d:6b:e8:48:d9:31:6c:4b:db:0c:82:47:
        25:a0:0c:58:56:b2:95:11:7a:58:b3:92:7e:91:c7:7e:15:58:
        e6:0e:06:01:0e:56:cb:85:35:f3:27:3a:4a:f8:ec:70:6d:c0:
        69:d9:98:bd:3e:72:e4:c8:1a:46:8d:54:a2:ad:65:bb:b3:e4:
        12:c4:e3:29:59:6a:bc:95:9a:d2:20:d5:27:51:4a:fc:f4:1c:
        9b:71:f3:b1:29:85:51:82:13:10:a8:58:c2:2c:81:4a:7f:be:
        f0:1b:7b:9e:ac:f8:bf:b7:ce:f1:18:57:d7:3a:df:91:a3:77:
        08:96:1a:41:78:3e:dd:65:cf:66:ac:e8:da:e6:c6:4b:ff:c9:
        4a:f6:b7:0f:07:90:a9:9b:a5:3c:bb:a2:d6:c6:92:c3:f6:00:
        37:a9:03:c3:d1:e6:bb:9f:cf:04:b5:dd:fe:bc:4f:9c:1e:68:
        df:e0:d0:ca:23:2d:a1:9b:1e:07:27:9c:09:6b:32:07:6d:e5:
        dd:c0:86:c0:58:0b:a4:10:86:38:fe:f7:40:29:da:d6:b5:b0:
        8a:b5:14:71:55:4b:15:4f:38:63:93:9f:57:b4:aa:90:23:96:
        fa:80:92:5d:c9:1b:df:56:b8:6a:db:8a:02:15:18:95:6a:5c:
        fe:0b:d0:e8:60:1e:79:14:f6:48:c8:b4:4a:7d:d0:ec:bc:f6:
        5a:75:89:83:e2:35:7d:97:be:21:22:f2:08:a5:da:63:76:8a:
        32:5b:66:1a:46:2d:60:48:73:c0:25:7c:70:75:16:77:e0:60:
        bc:9c:8e:2c:e3:71:17:5e:7b:22:e2:42:1d:7a:a0:34:c5:b6:
        56:12:fb:10:25:ae:22:7d:ce:3d:d8:32:5d:80:3c:99:e5:5a:
        78:df:05:53:73:07:2c:5e:96:50:6e:46:dc:49:34:9d:21:00:
        b2:bd:91:9b:55:6d:ed:ab:aa:d0:d9:0e:29:0f:66:ec:0b:22:
        6b:c4:48:54:43:b5:9a:0d:68:d1:5e:6d:40:d6:2e:8b:91:45:
        8b:12:a1:45:60:8b:d8:9f:a7:a4:42:46:83:0e:3c:e3:4f:1d:
        41:c8:49:a8:58:56:aa:36:06:23:03:25:65:da:f8:95:e2:13:
        61:80:77:53:0b:ad:f6:8b:2b:89:99:87:a4:3f:a0:44:0f:c6:
        49:01:10:41:c6:d0:ad:db:cd:39:2a:b0:7c:1d:ed:e7:e8:0d:
        64:fa:2b:18:8f:2a:71:d7:ed:f4:0e:22:cf:ea:26:f4:f0:b1:
        19:78:a6:22:60:42:54:06
Check that the request matches the signature
Signature ok
Everything appears to be ok, creating and signing the certificate
Successfully added extensions from config
The subject name appears to be ok, checking database for clashes
Certificate Details:
        Serial Number:
            3b:67:17:07:f2:51:59:b0:17:c9:76:30:cb:45:96:20:83:dd:28:5f
        Validity
            Not Before: Nov  9 06:29:42 2023 GMT
            Not After : Oct 16 06:29:42 2123 GMT
        Subject:
            domainComponent           = org
            domainComponent           = dataone
            commonName                = DataONE Test Intermediate CA
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                EF:2E:C1:27:6C:2A:8A:09:AB:6C:C3:45:7F:3B:F9:57:D5:16:A9:B3
            X509v3 Authority Key Identifier:
                42:55:08:AD:66:25:B4:BE:27:90:53:61:45:A2:35:6C:B9:FF:CA:B4
            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://releases.dataone.org/crl/DataONETest256CA_CRL.pem
                Full Name:
                  URI:http://cn-ucsb-1.dataone.org/crl/DataONETest256CA_CRL.pem
                Full Name:
                  URI:http://cn-orc-1.dataone.org/crl/DataONETest256CA_CRL.pem
Certificate is to be certified until Oct 16 06:29:42 2123 GMT (36500 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
writing new certificates
writing /var/ca/DataONETest256CA/newcerts/3B671707F25159B017C97630CB45962083DD285F.pem
Database updated
mbjones commented 11 months ago

Still TODO DONE -- modify the new DataONETest256IntCA to be configured for use with the ca shell script to generate new node certificates. These would be signed with the private key of the original DataONETestIntCA, as that was the key used to generate the CSR and is shared between the two intermediate roots. Need to test all this.

If all of this is working and tests out, set up the Prod CA the same way

artntek commented 9 months ago
  • [x] validate that NEW certs generated with the new 256 Int CA can be verified with both the old Int CA root cert and the new 256 Int CA root cert
  • [x] validate that OLD certs generated with the old Int CA can be verified with both the old Int CA root cert and the new 256 Int CA root cert

Testing details:

TEST CERTS
OLDROOTCA=./SHA-1_ARCHIVE/DataONETestCA/certs/DataONETestCA.pem
NEW256ROOTCA=./DataONETestRootCA/certs/DataONETestRootCA.pem
OLDINTERMED=./SHA-1_ARCHIVE/DataONETestIntCA/certs/DataONETestIntCA.pem
NEW256INTERMED=./DataONETestIntCA/certs/DataONETestIntCA.pem
OLDNODE=./urn_node_TestBROOKELT-sha1ca.pem
NEW256NODE=./DataONETestIntCA/certs/TEST:CERT:DELETEME-1-1.pem

PROD CERTS
OLDROOTCA=./SHA-1_ARCHIVE/DataONERootCA/certs/DataONERootCA.pem
NEW256ROOTCA=./DataONEProdRootCA/certs/DataONEProdRootCA.pem
OLDINTERMED=./SHA-1_ARCHIVE/DataONEProdCA/certs/DataONEProdCA.pem
NEW256INTERMED=./DataONEProdIntCA/certs/DataONEProdIntCA.pem
OLDNODE=./SHA-1_ARCHIVE/DataONEProdCA/certs/urn:node:SCTLD-1.pem
NEW256NODE=./DataONEProdIntCA/certs/prod:cert:DELETEME.pem
  1. validate that NEW certs generated with the new 256 Int CA can be verified with both the old Intermediate CA root cert… 
    
CA=$OLDROOTCA
INT=$OLDINTERMED
NODE=$NEW256NODE
echo "\n$CA -- $INT -- $NODE\n"
openssl verify -verbose -CAfile ${CA} -untrusted ${INT} ${NODE}

TEST: ./SHA-1_ARCHIVE/DataONETestCA/certs/DataONETestCA.pem -- ./SHA-1_ARCHIVE/DataONETestIntCA/certs/DataONETestIntCA.pem -- ./DataONETestIntCA/certs/TEST:CERT:DELETEME-1-1.pem

./DataONETestIntCA/certs/TEST:CERT:DELETEME-1-1.pem: OK

PROD: ./SHA-1_ARCHIVE/DataONERootCA/certs/DataONERootCA.pem -- ./SHA-1_ARCHIVE/DataONEProdCA/certs/DataONEProdCA.pem -- ./DataONEProdIntCA/certs/prod:cert:DELETEME.pem

./DataONEProdIntCA/certs/prod:cert:DELETEME.pem: OK


…and the new 256 Intermediate CA root cert
```shell
CA=$NEW256ROOTCA
INT=$NEW256INTERMED
NODE=$NEW256NODE
echo "\n$CA -- $INT -- $NODE\n"
openssl verify -verbose -CAfile ${CA} -untrusted ${INT} ${NODE}

TEST:
./DataONETestRootCA/certs/DataONETestRootCA.pem -- ./DataONETestIntCA/certs/DataONETestIntCA.pem -- ./DataONETestIntCA/certs/TEST:CERT:DELETEME-1-1.pem

./DataONETestIntCA/certs/TEST:CERT:DELETEME-1-1.pem: OK

PROD:
./DataONEProdRootCA/certs/DataONEProdRootCA.pem -- ./DataONEProdIntCA/certs/DataONEProdIntCA.pem -- ./DataONEProdIntCA/certs/prod:cert:DELETEME.pem

./DataONEProdIntCA/certs/prod:cert:DELETEME.pem: OK
  1. validate that OLD certs generated with the old Int CA can be verified with both the old Intermediate CA root cert… 
    
CA=$OLDROOTCA
INT=$OLDINTERMED
NODE=$OLDNODE
echo "\n$CA -- $INT -- $NODE\n"
openssl verify -verbose -CAfile ${CA} -untrusted ${INT} ${NODE}

TEST: ./DataONETestCA/certs/DataONETestCA.pem -- ./DataONETestIntCA/certs/DataONETestIntCA.pem -- ./urn_node_TestBROOKELT-1.pem

./urn_node_TestBROOKELT-1.pem: OK

PROD: ./SHA-1_ARCHIVE/DataONERootCA/certs/DataONERootCA.pem -- ./SHA-1_ARCHIVE/DataONEProdCA/certs/DataONEProdCA.pem -- ./SHA-1_ARCHIVE/DataONEProdCA/certs/urn:node:SCTLD-1.pem

./SHA-1_ARCHIVE/DataONEProdCA/certs/urn:node:SCTLD-1.pem: OK



…and the new 256 Intermediate CA root cert
```shell
CA=$NEW256ROOTCA
INT=$NEW256INTERMED
NODE=$OLDNODE
echo "\n$CA -- $INT -- $NODE\n"
openssl verify -verbose -CAfile ${CA} -untrusted ${INT} ${NODE}

TEST:
./DataONETest256CA/certs/DataONETest256CA.pem -- ./DataONETest256IntCA/certs/DataONETest256IntCA.pem -- ./urn_node_TestBROOKELT-1.pem

./urn_node_TestBROOKELT-1.pem: OK

PROD:
./DataONEProdRootCA/certs/DataONEProdRootCA.pem -- ./DataONEProdIntCA/certs/DataONEProdIntCA.pem -- ./SHA-1_ARCHIVE/DataONEProdCA/certs/urn:node:SCTLD-1.pem

./SHA-1_ARCHIVE/DataONEProdCA/certs/urn:node:SCTLD-1.pem: OK
artntek commented 9 months ago

The new SHA-256 CA cert chains have now been created and are currently in the feature-1-xsign-ca-creation branch (see PR #3), as follows:

DataONEProdCAChain.crt https://github.com/DataONEorg/ca/blob/feature-1-xsign-ca-creation/DataONEProdCAChain.crt

$ openssl crl2pkcs7 -nocrl -certfile DataONEProdCAChain.crt | openssl pkcs7 -print_certs -noout

subject=DC = org, DC = dataone, CN = DataONE Prod Root CA
issuer=DC = org, DC = dataone, CN = DataONE Prod Root CA

subject=DC = org, DC = dataone, CN = DataONE Production CA
issuer=DC = org, DC = dataone, CN = DataONE Prod Root CA

subject=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon Basic CA 1
issuer=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon Basic CA 1

subject=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon OpenID CA 1
issuer=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon OpenID CA 1

subject=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon Silver CA 1
issuer=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon Silver CA 1

DataONETestCAChain.crt https://github.com/DataONEorg/ca/blob/feature-1-xsign-ca-creation/DataONETestCAChain.crt

$ openssl crl2pkcs7 -nocrl -certfile DataONETestCAChain.crt | openssl pkcs7 -print_certs -noout

subject=DC = org, DC = dataone, CN = DataONE Test Root CA
issuer=DC = org, DC = dataone, CN = DataONE Test Root CA

subject=DC = org, DC = dataone, CN = DataONE Test Intermediate CA
issuer=DC = org, DC = dataone, CN = DataONE Test Root CA

subject=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon Basic CA 1
issuer=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon Basic CA 1

subject=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon OpenID CA 1
issuer=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon OpenID CA 1

subject=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon Silver CA 1
issuer=DC = org, DC = cilogon, C = US, O = CILogon, CN = CILogon Silver CA 1

The next step is to make a list of all the hosts where we need to update the cert chain, then start with the least risky and progress as we make sure things are working fine. @taojing2002 - I'm guessing you already have a list of hosts? Would you mind adding it here, in order of least to most risky?

taojing2002 commented 9 months ago

The hosts are:

taojing2002 commented 9 months ago

In mn-sandbox-ucsb-2, I set CipherString = DEFAULT:@SECLEVEL=2 from 0 in the file of /etc/ssl/openssl.cnf. Then restart apache. I could see the error messages in /var/log/apache/error.log:

[ssl:error] [pid 2338950:tid 139658187449920] [client 128.111.85.177:44920] AH02039: Certificate Verification: Error (68): CA signature digest algorithm too weak

Here are steps I did in mn-sandbox-ucsb-2 to replace the ca chain file:

  1. Download the new chain file: 
    Production servers: 
wget https://raw.githubusercontent.com/DataONEorg/ca/feature-1-xsign-ca-creation/DataONEProdCAChain.crt
Test servers:
wget https://raw.githubusercontent.com/DataONEorg/ca/feature-1-xsign-ca-creation/DataONETestCAChain.crt
  2. Copy the the new chain file to the apache CA chain file location (It seems we don't need c_rehash) 
    sudo cp DataONETestCAChain.crt /etc/ssl/certs/.
  3. Reload Apache: 
    sudo /etc/init.d/apache2 reload

    Note: make sure the chain file name and path match the property SSLCACertificateFile /etc/ssl/certs/DataONETestCAChain.crt in your enabled apache site file.

The sync works and the error messages are gone after we finished above steps!

taojing2002 commented 9 months ago

I will work with Rani to install the new ca chain file in PISCO. Maybe we can install the chain files in other servers when their dataone certificates expire.

taojing2002 commented 9 months ago

I replaced the ca chain on cn-sandbox-ucsb-1 and set the ssl level to 2. It still can harvest objects from member nodes which have or haven't had the new chain files. So it seems working.

artntek commented 9 months ago

I will work with Rani to install the new ca chain file in PISCO. Maybe we can install the chain files in other servers when their dataone certificates expire.

Thank you, @taojing2002! One thing to make Rani aware of, is that the new Prod cert chain has a different name than the old one it's replacing (old name: DataONECAChain.crt; new name: DataONEProdCAChain.crt).

(This is in contrast to the Test chains you installed above, which both have the same name.)

taojing2002 commented 9 months ago

Thanks, @artntek

artntek commented 9 months ago

resolved by PRs #2 and #3 and merged back to main