5 
$ curl -s https://goolge.ca | wc 
      0       0       0

$ curl -vs https://goolge.ca
. . .
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, bad certificate (554):
* SSL certificate problem: EE certificate key too weak
* Closing connection 0

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

Why this EE certificate key too weak problem?

I found a similiar problem, https://serverfault.com/questions/1033354/how-to-diagnose-ca-certificate-too-weak-error-how-to-use-the-ca-cert-anyway

but that one is CA certificate key too weak, I don't know if it the same as EE certificate key too weak.

Improve this question

1 Answer 1

Reset to default
3

By default, Debian has configured OpenSSL at security level 2, which provides 112 bits of security. That means that if one of the keys involved in the TLS connection, in this case the server's key (the end-entity certificate), provides a security level less than 112 bits (usually because the certificate is an RSA key smaller than 2048 bits), then it will be rejected.

Since a 112 bit security level is even below the recommended 128-bit minimum these days and this server is below even that, the best thing to do is to contact the server administrator and ask them to generate a new TLS certificate. With such an insecure certificate, a major corporation or a government could probably crack the key with some effort, and consequently spoof the connection.

If you can't do that, you can lower the security level by using curl --ciphers DEFAULT@SECLEVEL=1. Note that by doing this, you're essentially accepting that your connection is not completely secure and is subject to tampering.

Improve this answer
3
  • Thanks sir. By "server's key", did you mean google in my above example? That's really a big surprise to me, as I tested on google and github, all failed with the same error. Does it means such big sites are not using the recommended minimum security level? If google and github are not up to the standard, which is what I actually care, is there any system level setting that I can reduce system security level to 1? I know the risk, just want to know how technically it can be done. thx
    – xpt
    Commented Apr 8, 2021 at 2:27
  • You didn't actually specify Google there; your URL has a typo. But yes, the server is the remote website. Google and GitHub are definitely up to the right level, but if you're on a corporate network, then you may have a TLS MITM device on your network which is intercepting the traffic, in which case you should ask your IT department to either remove that device (preferred) or fix it so it's not a giant security problem.
    – bk2204
    Commented Apr 8, 2021 at 22:20
  • Yes, I'm on a corporate network that has a TLS MITM device which is intercepting the traffic. Thanks! Hmm... wait, the TLS MITM device is up to the standard too. I'll give more info...
    – xpt
    Commented Apr 9, 2021 at 12:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .