-
Notifications
You must be signed in to change notification settings - Fork 326
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
ca md too weak #682
Comments
See #673 You may be trying to connect to an obsolete FortiGate appliance This appliance seems to depend on weak algorithms that have been removed (by default or irremediably?) from the OpenSSL libraries bundled with Ubuntu 20.04. Have you tried the By the way, is this PKCS #12 certificate a personal certificate you need to authenticate with the VPN appliance? Would you happen to have some information on the model of FortiGate device and the version of FortiOS? If FortiOS is not too ancient you might find the information in the XML-formatted configuration sent by the FortiGate appliance and output by |
Also please provide more information on the certificate (sanitize before posting):
|
Thanks @DimitriPapadopoulos
Here's the cert info that you asked for. Please let me know if I've sanitized it too far. sanitized output of
sanitized output of
|
I don't use certificates to authenticate myself so I cannot tell for sure, but SHA-1 is known to be weak and obsolete. Also I have a client certificate as a first level of authentication for IPSec connections and it's based on SHA-256, not SHA-1. Perhaps that's the problem here. Are you comfortable with compiling your own version of openfortivpn? You may try to replace Line 969 in 77ec854
Line 980 in 77ec854
|
Also you may want to run
|
here's the code change:
This is the execution
|
The SSL_CTX_set_security_level man page shows that level 2 (the default on Ubuntu 20.04 as far as I can tell) should be sufficient to support the ciphers used by your FortiGate appliance. Perhaps you don't have the very latest version of FortiOS, but the cipher list is clearly more recent/secure than one one of the VPN appliances I connect to routinely:
I don't know yet how to get OpenSSL to accept SHA-1 certificates. Will keep looking. |
See for example:
As far as I can understand |
I think certificates are checked here: Line 927 in 77ec854
before security level is set according to --seclevel-1 :Lines 964 to 984 in 77ec854
I believe we need to move the whole part of the code that handles |
I tried moving things around. No luck yet |
In any case what did change in Debian 10 and Ubuntu 20.04 is the default security level moving from
Note the This is documented to cause this kind of interoperability issues in the SSL_CTX_set_security_level man page:
I am confident this is the problem at hand but I am also confident that this can be fixed programmatically from within openfortivpn because this is only a default setting. We just need to find a way to get back to |
@nirdothan What have you been trying so far? I don't have a personal certificate to test myself but I believe PR #685 should work for you. Can you give it a try? |
with PR #685 I still get the same error:
playing with cipher list still yields the same issue:
|
You still need By the way, does it work for you on Ubuntu 18.04? |
Also adding the following to
Does it help on Ubuntu 20.04? |
sorry, none of those seem to make a difference. I don't have Ubuntu 18.04 handy |
IT generated a new SHA-256 signed cert bundle for me and I am now able to connect. |
I would have loved to fix that in openfortivpn. I should be possible to set I guess the only way to investigate would be to generate an SHA-1 certificate and attempt to connect myself to a test FortiGate. |
Apart from the order, I think the problem is that we call SSL_set_cipher_list():
and this will apply only to the Instead we should call SSL_CTX_set_cipher_list():
|
I'm still here to test it if you have a new PR
…On Mon, May 4, 2020 at 12:42 PM Dimitri Papadopoulos Orfanos < ***@***.***> wrote:
Apart from the order, I think the problem is that we call
*SSL_set_cipher_list()*:
tunnel->ssl_handle = SSL_new(tunnel->ssl_context);
[...]
SSL_set_cipher_list(tunnel->ssl_handle, ...
and this will apply only to the tunnel->ssl_handle connection, not to
certificates.
Instead we should call *SSL_CTX_set_cipher_list()*:
SSL_CTX_set_cipher_list(tunnel->ssl_context, ...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#682 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABSUZOLPPIZXAJHNAODKOYTRP2EY3ANCNFSM4MXV7GYA>
.
|
@nirdothan I have updated the existing PR #685. Would you be willing to test it? |
@DimitriPapadopoulos I think that your fix works, unfortunately I could not connect, as I suspect that they revoked my old cert.
|
@nirdothan Thank you for checking, it really helps. Yes, I agree with you, I suspect the FortiGate closes the SSL connection as soon as it finds the certificate has been revoked. This change does get you further and I believe it would have worked all the way had the SHA-1 certificate not been revoked. This change makes total sense, does not seem to break other use cases, and does help in your case (up to some point at least). I think it's good for merging. |
Trying to connect with user cert and failing with the following error message:
SSL_CTX_use_certificate_file: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
If I understand correctly, the rejection is coming from openssl, and the option is either to configure openssl with
tls-cipher=DEFAULT:@SECLEVEL=0
or to rebuild the certificate. I'm not sure how to do either one.The certificate that I am using is originally a p12 file from which I've extracted the cert and key in PEM format.
running in ubuntu 20.04 LTS - 64-bit
The text was updated successfully, but these errors were encountered: