-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenSSL 1.1.0 & non-default vhost compatibility #13
Comments
Is not it already compatible? |
It doesn't work for non-default vhosts if you're using SNI. Still looking into it, it looks like |
Any news about the issue and an expectation when it will be fixed? |
I think it's a bug in OpenSSL: it looks like 1.1.0 invokes the SNI callback after I assume OpenSSL 1.0.2 invokes the SNI callback before setting |
I have confirmed this on my server. 1.0.2j could work but 1.1.0b couldn't. |
I just came across this module and I'm having the same problem with OpenSSL 1.1. Is there a bug filed with OpenSSL regarding this? I took a look at their github issue tracker and didn't seem to find anything relevant. |
I took a deeper look at the OpenSSL code and confirmed that SSL_set_SSL_CTX is wiping out the list of supported client extensions. It seems the TLS extension handling code was significantly refactored in 1.1.0 which is likely why the problem only shows up now. |
Thanks for reporting it to openssl. In the meantime, this is a very hacky patch I've been using to work around the issue:
|
FYI the patch will need updating for openssl 1.1.1. |
... and got it working:
|
This has been fixed upstream :) openssl/openssl@2118188 |
Confirmed. Thank you! |
OpenSSL 1.1.0f has been released with the fix. I've documented the bug in the README, so I think this can be closed now. |
Has anyone successfully got this working now that OpenSSL 1.1.0f is available? I'm encountering the same behavior as previous versions where the CT extension isn't appearing when a non-default server is used. I've confirmed nginx is built with the proper OpenSSL version, and I'm using the latest git master of nginx-ct.
Server block contains the following:
Can be verified by testing those IPs directly:
|
I understand you built against OpenSSL 1.1.0f, but are you absolutely positive that you are are running against 1.1.0f? Did you build OpenSSL statically? Which libssl/libcrypto .so files is nginx pointing to, and are they 1.1.0f?
|
I ma running nginx 1.12.0 with OpenSSL 1.1.0f and it works fine with many virtual hosts. |
@lukastribus I am definitely dynamically linking against OpenSSL 1.1.0f, I double checked this using ldd and strings to verify "OpenSSL 1.1.0f" was present in the libssl library. I also checked the entry under /proc/x/maps to make sure it hadn't somehow loaded a different library. @rraptorr I did a complete stop / start just to be 100% sure, it's definitely using the new libraries. I have tried with nginx-ct v1.3.2 with the same result. I've also tried downgrading to nginx 1.11.13 (which should match 1.12.0) in case the SSL renegotiation / TLS 1.3 support in 1.13 series changed things, but this also had no effect. |
Maybe it has something to do with you using RSA/ECDSA cert combo? I am using only one cert type per vhost (some RSA and some ECDSA). Maybe try to temporarily disable one of the certs? |
Figured out the problem. My default host wasn't using ssl_ct, which seems to cause all non-default hosts to also lose support. I wonder if this is a technical limitation with CT / TLS extensions or an issue with nginx-ct. |
No description provided.
The text was updated successfully, but these errors were encountered: