Upgrade the certificate chain for download.copr.fedorainfracloud.org to 3072 bit or longer RSA keys, to future-proof it and to allow using copr with FUTURE Fedora cryptographic policy.
# update-crypto-policies --set FUTURE Setting system policy to FUTURE Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. # curl https://download.copr.fedorainfracloud.org/results/phracek/PyCharm/fedora-36-x86_64/repodata/repomd.xml curl: (60) SSL certificate problem: EE certificate key too weak More details here: https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. # openssl s_client -connect download.copr.fedorainfracloud.org: 443 CONNECTED(00000003) depth=0 CN = download.copr.fedorainfracloud.org verify error:num=66:EE certificate key too weak verify return:1 depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon verify error:num=67:CA certificate key too weak verify return:1 depth=2 C = US, O = Amazon, CN = Amazon Root CA 1 verify error:num=67:CA certificate key too weak verify return:1 depth=2 C = US, O = Amazon, CN = Amazon Root CA 1 verify return:1 depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon verify return:1 depth=0 CN = download.copr.fedorainfracloud.org verify return:1 --- Certificate chain 0 s:CN = download.copr.fedorainfracloud.org i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Nov 30 00:00:00 2021 GMT; NotAfter: Dec 28 23:59:59 2022 GMT 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon i:C = US, O = Amazon, CN = Amazon Root CA 1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Oct 22 00:00:00 2015 GMT; NotAfter: Oct 19 00:00:00 2025 GMT 2 s:C = US, O = Amazon, CN = Amazon Root CA 1 i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", C N = Starfield Services Root Certificate Authority - G2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: May 25 12:00:00 2015 GMT; NotAfter: Dec 31 01:00:00 2037 GMT 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", C N = Starfield Services Root Certificate Authority - G2 i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certific ation Authority a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 2 00:00:00 2009 GMT; NotAfter: Jun 28 17:39:16 2034 GMT --- Server certificate -----BEGIN CERTIFICATE----- MIIF/DCCBOSgAwIBAgIQDECNiJQzvLf4Dtk9L+dpNjANBgkqhkiG9w0BAQsFADBG MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRUwEwYDVQQLEwxTZXJ2ZXIg Q0EgMUIxDzANBgNVBAMTBkFtYXpvbjAeFw0yMTExMzAwMDAwMDBaFw0yMjEyMjgy MzU5NTlaMC0xKzApBgNVBAMTImRvd25sb2FkLmNvcHIuZmVkb3JhaW5mcmFjbG91 ZC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCRw3XyGlw2vay4 +hI/i5S0IgRZiZFHgBTctYyma9ELtBIqwt50+Gz7m98CSPkyiOo2nU1+fG0BvDm7 uT/bg445UI7De0U0Hf2rzrDBpV1XjXrRu1u2CqIFAs+EAkPzmu2ybtNXNcgu+wV8 nA/O9JL0ncYA9tzTf6DDwghlXl/2QvbfIFsq+EBPnetDyJ2pnkkJMbpuyt+1c5Ha SWH9mzNTuNg0OHOd7B6QvLpCo16ITAdnLXpJJlsKvVlpAEl6PkHzS4MPXKqbfAxF f8eRW0BCy1fcp6PKkmZBIvxM4pw/qHCcrOXi4cKHSeSahxmPGqas+XnRuYBJsNjc 5vaFvROZAgMBAAGjggL9MIIC+TAfBgNVHSMEGDAWgBRZpGYGUqB7lZI8o5QHJ5Z0 W/k90DAdBgNVHQ4EFgQUwUCxlrWaF2XqIKs06loFDS2azAMwLQYDVR0RBCYwJIIi ZG93bmxvYWQuY29wci5mZWRvcmFpbmZyYWNsb3VkLm9yZzAOBgNVHQ8BAf8EBAMC BaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMD0GA1UdHwQ2MDQwMqAw oC6GLGh0dHA6Ly9jcmwuc2NhMWIuYW1hem9udHJ1c3QuY29tL3NjYTFiLTEuY3Js MBMGA1UdIAQMMAowCAYGZ4EMAQIBMHUGCCsGAQUFBwEBBGkwZzAtBggrBgEFBQcw AYYhaHR0cDovL29jc3Auc2NhMWIuYW1hem9udHJ1c3QuY29tMDYGCCsGAQUFBzAC hipodHRwOi8vY3J0LnNjYTFiLmFtYXpvbnRydXN0LmNvbS9zY2ExYi5jcnQwDAYD VR0TAQH/BAIwADCCAX4GCisGAQQB1nkCBAIEggFuBIIBagFoAHYARqVV63X6kSAw taKJafTzfREsQXS+/Um4havy/HD+bUcAAAF9b2eTlgAABAMARzBFAiAUBpIvdWLd 0chlv4hp8Q2QK5+/F4PbTtlW0nbYs0jWswIhAMRcrWny92I/OpsuKDPsoPUXDTER 99R//UfGqUVhvZtBAHYAUaOw9f0BeZxWbbg3eI8MpHrMGyfL956IQpoN/tSLBeUA AAF9b2eTpAAABAMARzBFAiBjuVF5VtSros40CtntBuvV8DaEZwx1x2SHJU9KrKtO EwIhAJfTvWxmL+Gh/OzlCAeZSZ6n/WSWtXGLD+1W9sdCTxyHAHYAQcjKsd8iRkoQ xqE6CUKHXk4xixsD6+tLx2jwkGKWBvYAAAF9b2eTZwAABAMARzBFAiEAq7wcbBJi 7U/76uTPZNHXSDsEZQp4myUSW85vD2UdFFECIHDppuHM+dH4k3QNFRZGYeNk3/5d 8yWNhKWPDPk6Yaq/MA0GCSqGSIb3DQEBCwUAA4IBAQBkPmYWOrjJQphhcj1qBRdG RgwsJRuX4xvlodeSc+w8qjrC6U1/d4rr3B1FIaYl4vffkY1XrrdAt1W9OrHA0NCJ a4EAPlRA4bCh800EUM9mxVmV+b6E0KhGIoK+E3ZcQ6DMsjfRmv6SztJiEnbxk5HK 5Argpt8ugEB4qDoqSVzDjZQF+uvOcrBtnJY5DGQTn3pmga+B7SVGzqUSZ1EzHgJN PmcibiFePlcoqW6KPU4fgVaZ7P+8gtBPrp6qe2bg6EtTrQQeKSRZRAu8b00FFyKK PtiB+q5/ToHDPiAyx4QdDHu2/CXyzOZOismVvPhYGLbVQIT/L7SmQoKN+/NlOryn -----END CERTIFICATE----- subject=CN = download.copr.fedorainfracloud.org issuer=C = US, O = Amazon, OU = Server CA 1B, CN = Amazon --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 5531 bytes and written 358 bytes Verification error: CA certificate key too weak --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 67 (CA certificate key too weak) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: 9FE8C023DED8705B01A2998E30DD45BF35A1DE693C8C3791AF6D24FDEE8E337A Session-ID-ctx: Resumption PSK: 670F6142A601C730E367C4AF73F9A0FE957F634957A9CF438F2BC9781CB3 14BFB7F60C8E885015E0B0BDFC9E5B1D0158 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 86400 (seconds) TLS session ticket: 0000 - 31 36 36 32 33 38 35 38-38 35 30 30 30 00 00 00 1662385885000... 0010 - a6 24 26 7b 18 16 eb 2d-cb e6 2c 7b d2 f9 97 7d .$&{...-..,{...} 0020 - 5f 2c 4c 1b 9f 5b 88 26-84 1a 9e 42 6e 69 db 13 _,L..[.&...Bni.. 0030 - bf ab 38 91 47 53 01 30-2a 41 e3 9b a2 74 73 11 ..8.GS.0*A...ts. 0040 - dd 63 4e 85 46 27 25 8b-a0 1e 71 93 a7 e1 f1 4f .cN.F'%...q....O 0050 - 90 c3 3f ca dc 4a 87 60-01 05 91 f4 f9 41 e5 3f ..?..J.`.....A.? 0060 - f2 7a cf 74 0f 66 d7 d5-2b 48 00 0f ba d3 dd ff .z.t.f..+H...... 0070 - 9b c9 2e 5c 98 d3 5a e6-e0 ...\..Z.. Start Time: 1662314754 Timeout : 7200 (sec) Verify return code: 67 (CA certificate key too weak) Extended master secret: no Max Early Data: 0 --- read R BLOCK
Not urgent, months (or even years?) would be fine.
A similar request for EPEL: https://bugzilla.redhat.com/show_bug.cgi?id=1832292
Metadata Update from @phsmoura: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: medium-gain, medium-trouble, ops
So, until letsencrypt can do this, the only way we have is via a special digicert path.
@praiskup If you like we could look into making a didigert for this? Or if you prefer to just wait for letsencrypt thats fine with me too.
IMHO, it's a nice to have, but not any kind of urgent thing...
This is Amazon CloudFront actually: https://download.copr.fedorainfracloud.org/
But letsencrypt probably has the same issue? https://copr.fedorainfracloud.org/ https://copr-be.cloud.fedoraproject.org/ https://copr-dist-git.fedorainfracloud.org/
FTR, we already track this: https://pagure.io/copr/copr/issue/2250
@praiskup If you like we could look into making a didigert for this?
I don't think we want to get back to manual certificate maintenance :-/ so I'm +1 for waiting for both LetsEncrypt and CloudFront.
waiting for both LetsEncrypt and CloudFront
Hm, what if they were not quick enough? I mean, lots of servers are using those ^^^ -- wouldn't the move to the FUTURE policy cause a big inconvenience?
Let'sEncrypt can do that, it's just that most acme clients default to 2048:
Supported Key Algorithms Let’s Encrypt accepts RSA keys that are 2048, 3072, or 4096 bits in length and P-256 or P-384 ECDSA keys. That’s true for both account keys and certificate keys. You can’t reuse an account key as a certificate key. Our recommendation is to serve a dual-cert config, offering an RSA certificate by default, and a (much smaller) ECDSA certificate to those clients that indicate support. (https://letsencrypt.org/docs/integration-guide) lots of servers are using those ^^^ -- wouldn't the move to the FUTURE policy cause a big inconvenience?
Supported Key Algorithms Let’s Encrypt accepts RSA keys that are 2048, 3072, or 4096 bits in length and P-256 or P-384 ECDSA keys. That’s true for both account keys and certificate keys. You can’t reuse an account key as a certificate key. Our recommendation is to serve a dual-cert config, offering an RSA certificate by default, and a (much smaller) ECDSA certificate to those clients that indicate support. (https://letsencrypt.org/docs/integration-guide)
lots of servers are using those ^^^ -- wouldn't the move to the FUTURE policy cause a big inconvenience?
I'm aware that lots of servers are using 2048 RSA by default, so even in the Fedora-39-targeting https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3 I concede and don't require >2048 RSA in DEFAULT policy. But we gotta move on someday, and if it can be today, why not today?
No. It's not that simple.
All the providers allow requesting certs with larger key sizes. The problem is those providers intermediate and root certs. Those MUST be the larger bit size too.
Because letsencrypt and other cert providers haven't moved to using their higher bit CA's and intermediates for normal cert requests. :(
Lets track this on the copr ticket and not here. :)
Metadata Update from @kevin: - Issue close_status updated to: Upstream - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.