SteveLTN / https-portal

A fully automated HTTPS server powered by Nginx, Let's Encrypt and Docker.
MIT License
4.46k stars 295 forks source link

prime256v1 no longer works? #302

Closed MarcelWaldvogel closed 1 year ago

MarcelWaldvogel commented 2 years ago

Apparently, prime256v1 certificates no longer work:

  1. I had problems with https-portal on ARM (official image) yesterday with clients complaining about "No common ciphers"; the only thing that fixed it was removing CERTIFICATE_ALGORITHM: 'prime256v1' from docker-compose.yml environment removing the old certificates and letting them recreate.

  2. Today, I wanted to verify whether this applies to ARM only. On x86_64 (a local docker build), it would not even create a certificate when CERTIFICATE_ALGORITHM was set to prime256v1:

    sh: 2: -noout: not found
    Can't open /var/lib/https-portal/host.example.ch/production/domain.ongoing.key for reading, No such file or directory
    139841220457600:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('/var/lib/https-portal/host.example.ch/production/domain.ongoing.key','r')
    139841220457600:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:
    unable to load Private Key
    Signing certificates from https://acme-v02.api.letsencrypt.org/directory ...
    Parsing account key...
    Parsing CSR...
    Traceback (most recent call last):
    File "/bin/acme_tiny", line 198, in <module>
       main(sys.argv[1:])
     File "/bin/acme_tiny", line 194, in main
       signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check,    directory_url=args.directory_url, contact=args.contact)
     File "/bin/acme_tiny", line 91, in get_crt
       out = _cmd(["openssl", "req", "-in", csr, "-noout", "-text"], err_msg="Error loading {0}".format(csr))
     File "/bin/acme_tiny", line 28, in _cmd
       raise IOError("{0}\n{1}".format(err_msg, err))
    IOError: Error loading /var/lib/https-portal/host.example.ch/production/domain.csr
    unable to load X509 request
    140396591793280:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: CERTIFICATE REQUEST
    
    ================================================================================
    Failed to sign host.example.ch.
    Make sure you DNS is configured correctly and is propagated to this host 
    machine. Sometimes that takes a while.
    ================================================================================
    Failed to obtain certs for host.example.ch

A quick web search did not reveal any deprecation statements and it is still listed in "modern ciphers". However, the certificate recommendation is for "P-256", but secp256r1, prime256v1, and NIST P-256 are equivalent.

Can anyone verify/refute this?

sarisia commented 1 year ago

I had problems with https-portal on ARM (official image) yesterday with clients complaining about "No common ciphers"; the only thing that fixed it was removing CERTIFICATE_ALGORITHM: 'prime256v1' from docker-compose.yml environment removing the old certificates and letting them recreate.

I ran into the same issue today.

Nginx config template does not seem to have appropriate ssl_ciphers for ECDSA certificates + TLSv1.2:

https://github.com/SteveLTN/https-portal/blob/b429a034907b2f195a6a724ab9c944a1864c61b7/fs_overlay/var/lib/nginx-conf/default.ssl.conf.erb#L20-L21

For workaround, adding few cipher suites to site config worked for me (Ref: https://github.com/SteveLTN/https-portal#override-just-one-single-sites-config):

- ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA;
+ ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA;

Available ciphers:

# openssl ciphers -v "aECDSA"
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(256) Mac=AEAD
ECDHE-ECDSA-ARIA256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=ARIAGCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(128) Mac=AEAD
ECDHE-ECDSA-AES128-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(128) Mac=AEAD
ECDHE-ECDSA-ARIA128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=ARIAGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=Camellia(256) Mac=SHA384
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=Camellia(128) Mac=SHA256
ECDHE-ECDSA-AES256-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-NULL-SHA    TLSv1 Kx=ECDH     Au=ECDSA Enc=None      Mac=SHA1