kvic-z/pixelserv-tls

Use 2048-bit RSA key to make pixelserv-tls work on Debian 10 "Buster"

emeidi opened this issue · 8 comments

emeidi commented

I recently upgraded to Debian 10 "Buster" and pixelserv-tls wouldn't work anymore.

The cryptic error messages in the log (debug level 4) read:

create_child_sslctx: cannot find or use $CERTDIR/_.google-analytics.com
tls_clienthello_cb: fail to create sslctx or cache _.google-analytics.com

After hacking around in cert.c and making the real SSL error messages appear if SSL_CTX_use_certificate_file or SSL_CTX_use_PrivateKey_file failed ...

...
    if(!SSL_CTX_use_certificate_file(sslctx, full_pem_path, SSL_FILETYPE_PEM)) {
        log_msg(LGG_ERR, "%s: SSL_CTX_use_certificate_file error for file %s with error %s\n", __FUNCTION__, full_pem_path, ERR_error_string( ERR_get_error(), NULL ));
    }
    if(!SSL_CTX_use_PrivateKey_file(sslctx, full_pem_path, SSL_FILETYPE_PEM)) {
        log_msg(LGG_ERR, "%s: SSL_CTX_use_PrivateKey_file error for file %s with error %s\n", __FUNCTION__, full_pem_path, ERR_error_string( ERR_get_error(), NULL ));
    }
...

I received the following error:

routines:SSL_CTX_use_certificate:ee key too small

which lead me to improve my ca.key generation line in my setup script to

openssl genrsa -out $CERTDIR/ca.key 2048

Unfortunately, the error wouldn't go away. I then realized that the key length is also hardcoded in cert.c:

...
if (RSA_generate_key_ex(rsa, 1024, e, NULL) < 0)
...

Once I changed this to 2048, everything is working fine again.

Thanks for patching

jrmwvu04 commented

Just to add this is also going to be an issue for macOS 10.15 and iOS 13 clients due to new enforcement rules.

https://support.apple.com/en-us/HT210176

"TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS."

slavkoja commented

I encounter this problem too, changing key size works, but with problem - the first request fails with this in log:

localhost localhost missing
read_tls_early_data error: 1 count: 0
handshake failed: client 127.0.0.1:45542 server localhost. Lib(20) Func(521) Reason(234)
cert generated to disk: localhost

After cert is generated, the second (and any next) request is success.

IMO, it is useless to generate new key for any domain. Nobody will care about security on deliberately empty response.

What about use predefined key file for all certs? And add some option to point to it, to anybody can generate and use desired key size. Or perhaps, generate it at start, if it is missing. Using predefined key will save some entropy and speed up operation, while only cert need to be generated.

jackyaz commented

My fork will generate compliant certificates: https://github.com/jackyaz/pixelserv-tls/releases/tag/2.3.0

PR'd here: #31

slavkoja commented

@jackyaz I tried your fork. Result is the same, at first request it fails, other requests seems OK (debian bullseye here).

jackyaz commented

That's how it's always worked for new domains, the certificate has to be generated

kvic-z commented

Very glad to see activities from the community on my hiatus & contributions to help each other!

v2.3.1 is released to conclude this tracker.

asaddon commented

@kvic-z Gald to see you back in action.

  • 👍1