Having difficulty connecting to my VPN and troubleshooting this I came across this post, I’ve added:
tls-cipher «DEFAULT:@SECLEVEL=0»
remote-cert-tls server
To my config it now kind of connects, however, keeps reconnecting/refreshing my logs says…
Wed Apr 18 19:21:21 2018 us=97512 No valid translation found for TLS cipher ‘@SECLEVEL=0’
Wed Apr 18 19:21:21 2018 us=98512 LZO compression initializing
Wed Apr 18 19:21:21 2018 us=98512 Control Channel MTU parms [ L:1654 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Wed Apr 18 19:21:21 2018 us=98512 Data Channel MTU parms [ L:1654 D:1450 EF:122 EB:411 ET:32 EL:3 ]
Wed Apr 18 19:21:21 2018 us=98512 Local Options String (VER=V4): ‘V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client’
Wed Apr 18 19:21:21 2018 us=98512 Expected Remote Options String (VER=V4): ‘V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server’
Wed Apr 18 19:21:21 2018 us=99012 TCP/UDP: Preserving recently used remote address: [AF_INET]188.240.175.69:12974
Wed Apr 18 19:21:21 2018 us=99012 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Apr 18 19:21:21 2018 us=99012 UDP link local: (not bound)
Wed Apr 18 19:21:21 2018 us=99012 UDP link remote: [AF_INET]188.240.175.69:12974
Wed Apr 18 19:21:21 2018 us=99012 MANAGEMENT: >STATE:1524075681,WAIT,,,,,,
Wed Apr 18 19:21:21 2018 us=123534 MANAGEMENT: >STATE:1524075681,AUTH,,,,,,
Wed Apr 18 19:21:21 2018 us=123534 TLS: Initial packet from [AF_INET]188.240.175.69:12974, sid=b8f749bc 94d2f334
Wed Apr 18 19:21:21 2018 us=274714 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=netgear, OU=netgear, CN=netgear, emailAddress=mail@netgear.com
Wed Apr 18 19:21:21 2018 us=275209 Certificate does not have key usage extension
Wed Apr 18 19:21:21 2018 us=275209 VERIFY KU ERROR
Wed Apr 18 19:21:21 2018 us=275209 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Wed Apr 18 19:21:21 2018 us=275209 TLS_ERROR: BIO read tls_read_plaintext error
Wed Apr 18 19:21:21 2018 us=275209 TLS Error: TLS object -> incoming plaintext read error
Wed Apr 18 19:21:21 2018 us=275209 TLS Error: TLS handshake failed
Wed Apr 18 19:21:21 2018 us=275671 TCP/UDP: Closing socket
Wed Apr 18 19:21:21 2018 us=275671 SIGUSR1[soft,tls-error] received, process restarting
Wed Apr 18 19:21:21 2018 us=275671 MANAGEMENT: >STATE:1524075681,RECONNECTING,tls-error,,,,,
Wed Apr 18 19:21:21 2018 us=275671 Restart pause, 5 second(s)
Wed Apr 18 19:21:26 2018 us=278750 Re-using SSL/TLS context
Wed Apr 18 19:21:26 2018 us=278750 LZO compression initializing
Wed Apr 18 19:21:26 2018 us=279194 Control Channel MTU parms [ L:1654 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Wed Apr 18 19:21:26 2018 us=279194 Data Channel MTU parms [ L:1654 D:1450 EF:122 EB:411 ET:32 EL:3 ]
Wed Apr 18 19:21:26 2018 us=279194 Local Options String (VER=V4): ‘V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client’
Wed Apr 18 19:21:26 2018 us=279194 Expected Remote Options String (VER=V4): ‘V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server’
Wed Apr 18 19:21:26 2018 us=279194 TCP/UDP: Preserving recently used remote address: [AF_INET]188.240.175.69:12974
Wed Apr 18 19:21:26 2018 us=279194 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Apr 18 19:21:26 2018 us=279194 UDP link local: (not bound)
Wed Apr 18 19:21:26 2018 us=279194 UDP link remote: [AF_INET]188.240.175.69:12974
Wed Apr 18 19:21:26 2018 us=279694 MANAGEMENT: >STATE:1524075686,WAIT,,,,,,
Wed Apr 18 19:21:26 2018 us=304217 MANAGEMENT: >STATE:1524075686,AUTH,,,,,,
Wed Apr 18 19:21:26 2018 us=304217 TLS: Initial packet from [AF_INET]188.240.175.69:12974, sid=cd35f207 20a8cc76
Wed Apr 18 19:21:26 2018 us=452850 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=netgear, OU=netgear, CN=netgear, emailAddress=mail@netgear.com
Wed Apr 18 19:21:26 2018 us=453353 Certificate does not have key usage extension
Wed Apr 18 19:21:26 2018 us=453353 VERIFY KU ERROR
Wed Apr 18 19:21:26 2018 us=453353 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Wed Apr 18 19:21:26 2018 us=453353 TLS_ERROR: BIO read tls_read_plaintext error
Wed Apr 18 19:21:26 2018 us=453353 TLS Error: TLS object -> incoming plaintext read error
Wed Apr 18 19:21:26 2018 us=453353 TLS Error: TLS handshake failed
Wed Apr 18 19:21:26 2018 us=453850 TCP/UDP: Closing socket
Wed Apr 18 19:21:26 2018 us=453850 SIGUSR1[soft,tls-error] received, process restarting
Wed Apr 18 19:21:26 2018 us=453850 MANAGEMENT: >STATE:1524075686,RECONNECTING,tls-error,,,,,
Wed Apr 18 19:21:26 2018 us=454351 Restart pause, 5 second(s)
Wed Apr 18 19:21:29 2018 us=455072 SIGTERM[hard,init_instance] received, process exiting
Wed Apr 18 19:21:29 2018 us=455519 MANAGEMENT: >STATE:1524075689,EXITING,init_instance,,,,,
Can anyone help?
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
Comments
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
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 --insecure-ssl, --min-tls and --seclevel-1 options?
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 openfortivpn -v -v. It would help if you could show us the (sanitized) piece of information.
Also please provide more information on the certificate (sanitize before posting):
openssl x509 -text -in <certificate_file.pem>
openssl x509 -nokeys -info -in <keystore.p12>
Thanks @DimitriPapadopoulos
An obsolete FortiGate appliance on the other end is quite possible.
I’ll try to find out version information from IT, hopefully by tomorrow.
--insecure-ssl, --min-tls and --seclevel-1 didn’t help
Here’s the cert info that you asked for. Please let me know if I’ve sanitized it too far.
sanitized output of openssl x509 -text -in <certificate_file.pem>
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4283 (0x10bb)
Signature Algorithm: sha1WithRSAEncryption
Issuer: REDACTED
Validity
Not Before: Jul 27 11:42:04 2017 GMT
Not After : Jul 27 11:42:04 2037 GMT
Subject: REDACTED
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
REDACTED
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: sha1WithRSAEncryption
REDACTED
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
sanitized output of openssl pkcs12 -nokeys -info -in <keystore.p12>
Bag Attributes
friendlyName: nird
localKeyID: 6E REDACTED A3
subject=C = REDACTED
issuer=C = REDACTED
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
Bag Attributes: <No Attributes>
subject= REDCATED
issuer=C = REDACTED
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
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 @SECLEVEL=1 with @SECLEVEL=0 in the following lines and run openfortivpn --insecure-ssl --seclevel-1 again:
| cipher_list = «HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4@SECLEVEL=1«; |
| const char *cipher_list = «DEFAULT@SECLEVEL=1«; |
Also you may want to run nmap --script ssl-enum-ciphers against you VPN appliance and post here the (saniitized) output to have a look at supported ciphers. For example:
$ nmap --script ssl-enum-ciphers -p 443 www.fortinet.com
Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-02 00:00 UTC
Nmap scan report for www.fortinet.com (13.56.33.144)
Host is up (0.17s latency).
rDNS record for 13.56.33.144: ec2-13-56-33-144.us-west-1.compute.amazonaws.com
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CCM_8 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048) - A
| TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CCM_8 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048) - A
| TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CCM_8 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CCM (rsa 2048) - A
| TLS_RSA_WITH_ARIA_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CCM_8 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CCM (rsa 2048) - A
| TLS_RSA_WITH_ARIA_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A
Nmap done: 1 IP address (1 host up) scanned in 34.80 seconds
$
here’s the code change:
diff --git a/src/tunnel.c b/src/tunnel.c
index 4a3da5e..0e20bb2 100644
--- a/src/tunnel.c
+++ b/src/tunnel.c
@@ -966,7 +966,7 @@ int ssl_connect(struct tunnel *tunnel)
const char *cipher_list;
if (tunnel->config->seclevel_1)
- cipher_list = "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4@SECLEVEL=1";
+ cipher_list = "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4@SECLEVEL=0";
else
cipher_list = "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4";
tunnel->config->cipher_list = strdup(cipher_list);
@@ -977,7 +977,7 @@ int ssl_connect(struct tunnel *tunnel)
tunnel->config->min_tls = TLS1_VERSION;
#endif
if (!tunnel->config->cipher_list && tunnel->config->seclevel_1) {
- const char *cipher_list = "DEFAULT@SECLEVEL=1";
+ const char *cipher_list = "DEFAULT@SECLEVEL=0";
tunnel->config->cipher_list = strdup(cipher_list);
}
This is the execution
sudo /usr/local/bin/openfortivpn -u nird --min-tls 1.0 --insecure-ssl --seclevel-1 --user-cert=***.crt.pem --user-key=***key.pem host:port -v
DEBUG: openfortivpn 1.13.3
DEBUG: revision v1.13.3+git43.g77ec854
WARN: Could not load config file "/etc/openfortivpn/config" (No such file or directory).
VPN account password:
DEBUG: Config host = "***"
DEBUG: Config realm = ""
DEBUG: Config port = "***"
DEBUG: Config username = "***"
DEBUG: Resolving gateway host ip
DEBUG: Establishing ssl connection
DEBUG: server_addr: ***
DEBUG: server_port: ***
DEBUG: gateway_addr: ***
DEBUG: gateway_port: ***
ERROR: SSL_CTX_use_certificate_file: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
INFO: Closed connection to gateway.
DEBUG: server_addr: ***
DEBUG: server_port: ***
DEBUG: gateway_addr: ***
DEBUG: gateway_port: ***
ERROR: SSL_CTX_use_certificate_file: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
INFO: Could not log out.
PORT STATE SERVICE
***/tcp open https
| ssl-enum-ciphers:
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| REDACTED
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CCM_8 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CCM_8 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CCM (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CCM_8 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CCM_8 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CCM (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| REDACTED
|_ least strength: C
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:
$ Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-02 00:00 UTC
Nmap scan report for xxxxxxxxxxxxx.xxx.xx (xxx.xxx.xxx.xxx)
Host is up (0.027s latency).
rDNS record for xxx.xxx.xxx.xxx: xxxxxxx.xxxxx.xxx.xx
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CCM_8 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048) - A
| TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (secp256r1) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CCM_8 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CCM (rsa 2048) - A
| TLS_RSA_WITH_ARIA_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CCM_8 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048) - A
| TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CCM_8 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CCM (rsa 2048) - A
| TLS_RSA_WITH_ARIA_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
|_ least strength: C
Nmap done: 1 IP address (1 host up) scanned in 7.92 seconds
$
I don’t know yet how to get OpenSSL to accept SHA-1 certificates. Will keep looking.
I think certificates are checked here:
| if (!SSL_CTX_use_PrivateKey_file( |
before security level is set according to --seclevel-1:
| if (!tunnel->config->insecure_ssl) { | |
| if (!tunnel->config->cipher_list) { | |
| const char *cipher_list; | |
| if (tunnel->config->seclevel_1) | |
| cipher_list = «HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4@SECLEVEL=1«; | |
| else | |
| cipher_list = «HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4«; | |
| tunnel->config->cipher_list = strdup(cipher_list); | |
| } | |
| } else { | |
| #if OPENSSL_VERSION_NUMBER >= 0x10100000L | |
| if (tunnel->config->min_tls <= 0) | |
| tunnel->config->min_tls = TLS1_VERSION; | |
| #endif | |
| if (!tunnel->config->cipher_list && tunnel->config->seclevel_1) { | |
| const char *cipher_list = «DEFAULT@SECLEVEL=1«; | |
| tunnel->config->cipher_list = strdup(cipher_list); | |
| } | |
| } |
I believe we need to move the whole part of the code that handles --insecure-ssl, --seclevel-1, --min-tls and calls SSL_set_cipher_list() before messing with certificates.
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 @SECLEVEL=1 to @SECLEVEL=2:
$ openssl version -a
OpenSSL 1.1.1f 31 Mar 2020
built on: Mon Apr 20 11:53:50 2020 UTC
platform: debian-amd64
options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-P_ODHM/openssl-1.1.1f=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific
$
Note the -DOPENSSL_TLS_SECURITY_LEVEL=2 OpenSSL compilation option.
This is documented to cause this kind of interoperability issues in the SSL_CTX_set_security_level man page:
WARNING at this time setting the security level higher than 1 for general internet use is likely to cause considerable interoperability issues and is not recommended. This is because the SHA1 algorithm is very widely used in certificates and will be rejected at levels higher than 1 because it only offers 80 bits of security.
The default security level can be configured when OpenSSL is compiled by setting -DOPENSSL_TLS_SECURITY_LEVEL=level. If not set then 1 is used.
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 @SECLEVEL=1 for certificates.
@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:
DEBUG: openfortivpn 1.13.3
DEBUG: revision v1.6.0+git277.g32bd42a
DEBUG: Loaded config file "/etc/openfortivpn/config".
DEBUG: Loaded password from config file "/etc/openfortivpn/config"
DEBUG: Config host = ***
DEBUG: Config realm = ""
DEBUG: Config port = "***"
DEBUG: Config username = "***"
DEBUG: Resolving gateway host ip
DEBUG: Establishing ssl connection
DEBUG: server_addr: ***
DEBUG: server_port: ***
DEBUG: gateway_addr: ***
DEBUG: gateway_port: ***
DEBUG: Setting cipher list to: HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4
ERROR: SSL_CTX_use_certificate_file: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
INFO: Closed connection to gateway.
DEBUG: server_addr: ***
DEBUG: server_port: ***
DEBUG: gateway_addr: ***
DEBUG: gateway_port: ***
DEBUG: Setting cipher list to: HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4
ERROR: SSL_CTX_use_certificate_file: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
INFO: Could not log out.
playing with cipher list still yields the same issue:
DEBUG: Setting cipher list to: HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4@SECLEVEL=1
DEBUG: Setting min proto version to: 0x301
ERROR: SSL_CTX_use_certificate_file: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
You still need --seclevel-1 and perhaps --min-tls=1.2.
By the way, does it work for you on Ubuntu 18.04?
Also adding the following to /etc/ssl/openssl.cnf seems to be working on Debian 10, although it’s an ugly workaround:
[system_default_sect]
CipherString = DEFAULT@SECLEVEL=1
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.
Thanks a lot @DimitriPapadopoulos for your help
I would have loved to fix that in openfortivpn. I should be possible to set @SECLEVEL=1 for certificates since it works for communication with the FortiGate appliance (see #673).
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():
tunnel->ssl_context = SSL_CTX_new(SSLv23_client_method());
[...]
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():
tunnel->ssl_context = SSL_CTX_new(SSLv23_client_method());
[...]
SSL_CTX_set_cipher_list(tunnel->ssl_context, ...
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.
With the new cert, it connects fine, so as far as regression goes, your PR didn’t break anything.
DEBUG: openfortivpn 1.13.3
DEBUG: revision v1.6.0+git278.gfe46c2c
DEBUG: Loaded config file "config-cert".
DEBUG: Loaded password from config file "config-cert"
DEBUG: Config host = ***
DEBUG: Config realm = ""
DEBUG: Config port = "***"
DEBUG: Config username = "***"
DEBUG: Resolving gateway host ip
DEBUG: Establishing ssl connection
DEBUG: server_addr: ***
DEBUG: server_port: ***
DEBUG: gateway_addr: ***
DEBUG: gateway_port: ***
DEBUG: Setting cipher list to: DEFAULT@SECLEVEL=1
DEBUG: Setting min proto version to: 0x301
DEBUG: Gateway certificate validation failed.
DEBUG: Gateway certificate digest found in white list.
INFO: Connected to gateway.
DEBUG: Error reading from SSL connection (Protocol violation with EOF).
DEBUG: server_addr: ***
DEBUG: server_port: ***
DEBUG: gateway_addr: ***
DEBUG: gateway_port: ***
DEBUG: Setting cipher list to: DEFAULT@SECLEVEL=1
DEBUG: Setting min proto version to: 0x301
DEBUG: Gateway certificate validation failed.
DEBUG: Gateway certificate digest found in white list.
DEBUG: Error reading from SSL connection (Protocol violation with EOF).
DEBUG: Error issuing /remote/logincheck request
ERROR: Could not authenticate to gateway. Please check the password, client certificate, etc.
DEBUG: SSL error -4
INFO: Closed connection to gateway.
DEBUG: server_addr: ***
DEBUG: server_port: ***
DEBUG: gateway_addr: ***
DEBUG: gateway_port: ***
DEBUG: Setting cipher list to: DEFAULT@SECLEVEL=1
DEBUG: Setting min proto version to: 0x301
DEBUG: Gateway certificate validation failed.
DEBUG: Gateway certificate digest found in white list.
INFO: Logged out.
@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.
2 participants
Посмотрите https://forum.altlinux.org/index.php?topic=8557.msg163936#msg163936
и ниже.
Что-то с ключами.
Создайте по новой. Попробуйте варианты.
Проверьте работу сервера.
В части предложенной ссылки:
Создайте по новой. Попробуйте варианты.
В приведенной ссылке сказано:
Шаг № 1 Получаем готовые файлы
/var/lib/ssl/private/vova.key
/var/lib/ssl/certs/openvpn-client-CA.crt
/var/lib/ssl/certs/vova.cert
А процедура их генерации какая правильная?
Если не «берем ранее полученные» а «если надо добавить windows-клиента», то … ?
Я для генерации использовал создание нового ключа в разделе управления ssl-ключами (через веб-интерфейс) и подписывал полученный ключ в сооветствующем разделе УЦ, далее получил файл ответа (pem), брал подписанный (в примере это vova.cert), файл ключа брал с сервера сертификации и openvpn-client-CA.crt — это pem удостоверяющего центра. Потом забирал файлы по указанным путям полученные сертификаты.
Есть вариант сгенерировать комплект ключей посредством консоли? Так чтобы они выпали в конкретное место?
А также возник вопрос/просьба объяснить алгоритм работы (логику):
Есть УЦ на одной машине, есть openvpn сервер на другой. Как они связаны? Как работает «обновление сертификатов», если я на openvpn-сервере создал сертификат, перенёс его руками на другой ПК и подписал в УЦ — процесс закончился тем, что я получил файл ответа — и дальше что? На сервере я не нашёл «слепка» подписанного сертификата. Если пользователь (или удалённая сеть), скажем по-турецки, ёк, то что? УЦ сменился и всем переделывать сертификаты (ибо не сохранив старый уц мы не можем пересоздать сертификаты, но они работают до окончания срока их работы). А автообновление сертификатов — на кой оно? Только для внутренних сервисов?
И да, сертификат openvpn-сервера подтверждает только логин соединения? Так как всё, что есть у vpn-сервера — это наименование соединения, а сертификат — это только подтверждения принадлежности устанавливающего соединение к имени, которым он предствляется?
Простите, если вопросы покажутся глупыми, но … пока я много чего не понимаю, или не правильно использую.
И вообще, правильно ли я понимаю, что в приведенном примере:
vova.key получаем на сервере сертификации
openvpn-client-CA.crt — корневой сертификат удостоверяющего центра
vova.cert — это файл ответа (исходно pem-файл, получаемый в УЦ)?
On Ubunto 16 I’ve configured openVPN with password with Certificate (TSL)
my config file is:
dev tun
remote XX.XX.XXX.X
ca ca.crt
cert user_name.crt
key user_name.key
ns-cert-type server
It does work well.
My workstation has Ubuntu 19.04 and I can’t connect, I get the error:
Thu Oct 17 00:01:15 2019 WARNING: file ‘user_name.key’ is group or
others accessible Thu Oct 17 00:01:15 2019 OpenVPN 2.4.6
x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11]
[MH/PKTINFO] [AEAD] built on May 14 2019 Thu Oct 17 00:41:15 2019
library versions: OpenSSL 1.1.1b 26 Feb 2019, LZO 2.10 Thu Oct 17
00:01:15 2019 WARNING: —ns-cert-type is DEPRECATED. Use
—remote-cert-tls instead. Thu Oct 17 00:01:15 2019 OpenSSL: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak Thu
Oct 17 00:41:15 2019 Cannot load certificate file user_name.crt Thu Oct
17 00:01:15 2019 Exiting due to fatal error
user_name.crt and all other files are located at /etc/openvpn
Is there some differences between Ubuntu 16 and 19 regarding VPN certificates?
Or is it possible that because I first connected (successfully) with the Ubunto 16, now the VPN server is only accepted connections from this machine/user?
asked Oct 16, 2019 at 22:46
Is there some differences between Ubuntu 16 and 19 regarding VPN certificates?
Ubuntu 19 has increased the requirements for accepted certificates in general, not only for VPN. Make sure that you have for an RSA certificate at least a key size of 2048 and that at least SHA-2 is used for the signature.
answered Oct 17, 2019 at 4:54
2
Infopackets Reader Steve T. writes:
» Dear Dennis,
I recently upgraded my OpenVPN from version 2.3.2 (back in 2014) to the latest version 2.4.6, but now my OpenVPN server is broken. I checked the log files and it says ‘SSL routines:SSL_CTX_use_certificate:ca md too weak‘, followed by ‘Cannot load certificate file /path/cert.crt’. I have tried embedding my certificates inside the server.ovpn file (rather than having it point somewhere externally), but that does not help. It simply won’t load the certificate. I’ve researched this issue for days and keep coming across
a forum post on the OpenVPN site but it doesn’t make any sense to me. Can you PLEASE HELP?! «
My response:
I asked Steve if he would like to connect with me using my
remote desktop service in order to have a closer look, and he agreed.
I examined the forum post Steve referenced, with some users suggesting to place «DEFAULT:@SECLEVEL=0» directive inside the configuration file, but that would bypass any certificates and thus completely remove any security the VPN has to offer and is therefore NOT recommended. Other users suggested recreating all the certificates, but that did not work either.
Another user suggested modifying the «openssl-1.0.0.cnf» configuration file, which is part of the OpenSSL package, which is used to generate certificates. Essentially, the «default_md» directive must be changed from «md5» to «sha256«, otherwise OpenVPN craps out with the «SSL routines:SSL_CTX_use_certificate:ca md too weak» error message.
Further research into this issue suggests that MD5 is no longer secure enough when used in conjunction with generating certificates and that OpenSSL version 1.1 now uses SHA256 instead of MD5. For whatever reason the latest version of OpenVPN (version 2.4.6) does not have this directive changed, so you must manually modify the openssl-1.0.0.cnf configuration file to get around the problem.
How to Fix: OpenVPN ‘SSL_CTX_use_certificate:ca md too weak’
Now that we understand the issue, here is what you need to do.
- If you are using Windows, open notepad or your favorite text editor and point to C:Program FilesOpenVPNeasy-rsa, then load the file openssl-1.0.0.cnf. If you are using Linux, the path would be /etc/openvpn/easy-rsa/openssl-1.0.0.cnf or similar. If that doesn’t work, just do a search for «openssl-1.0.0.cnf» using ‘find’ or ‘mlocate’.
- Scroll down to the «default_md» directive and change it from «md5» to «sha256», then save the configuration file.
- Regenerate your server keys (ca.crt, server.crt, server.key, dh4096.pem, ta.key), then recreate your server.ovpn file and include the certificates inside the file
using the appropriate directives. Do not create and client files yet until you know the server.ovpn file is working. I suggest using the ‘verb 3’ directive as this should provide enough verbage if there are any errors.
- The best way to test the newly created server.ovpn file is to launch an administrative command prompt, then run openvpn executable by pointing it to your configuration file, rather than through the graphical user interface or services.msc. For example, the line below would launch the server.ovpn file if it was located in the «config» folder — quotes must be used for the paths if they contain spaces.
«C:Program FilesOpenVPNbinopenvpn.exe» «C:Program FilesOpenVPNconfigserver.ovpn»
- If you get an «Initialization Sequence Completed» — meaning that the server configuration file loaded successfully, then next step is to open another administrative command prompt and ping your OpenVPN server’s IP (according to what you specified in the config file) and see if you get a response. In my case the server’s IP is 10.10.0.1, so I would enter:
ping 10.10.0.1
You should see something like this:
Pinging 10.10.0.1 with 32 bytes of data:
Reply from 10.10.0.1: bytes=32 time=24ms TTL=128
Reply from 10.10.0.1: bytes=32 time=24ms TTL=128
Reply from 10.10.0.1: bytes=32 time=24ms TTL=128
Reply from 10.10.0.1: bytes=32 time=25ms TTL=128If you did, pat yourself on the back for a job well done.
- Recreate your client configuration files using similar methods to create the server configuration file, then launch another administrative command prompt and try and connect to your server. It should work.
I highly suggest using «cipher AES-256-CBC» in both client and server configuration files as this offers the most encryption available, plus
it is what’s recommended by the openvpn site.
The default setting is Blowfish encryption, but is not enough and
susceptible to the
SWEET32 attack.
I hope that helps.
Additional 1-on-1 Support: From Dennis
If all of this is over your head, or if you need help configuring your OpenVPN server and clients, I can help using my
remote desktop support service. Simply contact me, briefly describing the issue and I will get back to you as soon as possible.
About the author: Dennis Faas is the owner and operator of
Infopackets.com. With over 30 years of computing experience, Dennis’ areas of
expertise are a broad range and include PC hardware, Microsoft Windows, Linux,
network administration, and virtualization. Dennis holds a Bachelors degree in
Computer Science (1999) and has authored 6 books on the topics of MS Windows and
PC Security. If you like the advice you received on this page, please up-vote /
Like this page and share it with friends. For technical support inquiries,
Dennis can be reached via Live chat online this site using the Zopim Chat
service (currently located at the bottom left of the screen); optionally, you
can contact Dennis through the website
contact form.
Сегодня разберём как подключить Debian к микротику посредствам OpenVPN. Ранее мы уже разбирали как поднять VPN сервер на микротике, поэтому будем разбирать как подключится к нему с Linux.
Установка
Пожалуй на дебиане настройка выполняется самым простым образом. Первоначально нам надо установить пакет. Никаких сложностей, воспользуемся обычным менеджером пакетов, никаких новых репозиториев нам не нужно.
после установки переходим в каталог /etc/openvpn/client и создаём файлик client.conf следующего содержания:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
proto tcp—client # в этой строчке мы указываем адрес в интернете нашего микротика remote 123.123.123.123 dev tap nobind persist—key tls—client #указываем имена публичного CA сертификата ca ca.crt # публичного сертификата клиента cert client.crt # и его закрытый ключ key client.key #каждые 10 секунд проверять туннель, если нет ответа 120 секунд, переподключаться keepalive 10 120 verb 3 #проверка сертификата сервера #https://openvpn.net/index.php/open-source/documentation/howto.html#mitm remote—cert—tls server cipher AES—256—CBC auth SHA1 pull # эта строка задаёт файл с логином-паролем которые мы прописывали в PPP-Secrets на микротике auth—user—pass auth.cfg # в этой части мы задаём настройки сетей которые находятся за микротиком, # в моём случае 192.168.1.0 с маской 255.255.255.0 это сеть, # а 192.168.221.1 это адрес микротика который мы указывали в PPP профиле route—delay 2 route 192.168.1.0 255.255.255.0 192.168.221.1 |
в этой же папке создаём файл auth.cfg куда записываем логин-пароль
Сюда же скидываем сертификаты: клиента, CA и секретный ключ клиента. После того как все файлы готовы можно запускать службу. В 9 дебиане это делается через systemd
|
systemctl start openvpn—client@client |
Тут добавлю немножко деталей. openvpn-client — значит запустить конфиг из папки /etc/openvpn/client, а @client значит запустить конфиг с названием client (файл в папке с именем client.conf). Соответственно таким же образом мы можем все файлы накидать в папку server и запуститься командой systemctl start openvpn-server@client. В какую именно папку закидывать конфиг и как запускаться зависит только от Вас.
Failed to enable unit: Unit file openvpn.service does not exist.
Ещё есть момент, что на разных системах работает эта команда по разному, например в ubuntu надо сложить файлы в /etc/openvpn, а запускать сервис командой: systemctl start openvpn@client.
Проверяем всё ли в порядке командой ifconfig, должен появится новый интерфейс
Если интерфейса нет, смотрим лог файлы
|
tail —n 100 /var/log/syslog |
OpenSSL: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
Эта ошибка означает что у вас сгенерирован сертификат с использованием md5, что сейчас считается небезопасным, обновите скрипт который генерировал сертификат и создайте заново всю цепочку ca-server-client. Проверял начиная с 2.4.6 используется sha256, не знаю как более ранние, но более поздние точно нормально генерируют.
Если же всё в порядке добавляем службу в автозапуск
|
systemctl enable openvpn—client@client |
На этом всё.
Как и прежде любые вопросы или пожелания можно оставлять ниже в комментариях.