I am using PHP v7.2, on Windows 10 Computer and Composer version 1.9.0
composer create-project --prefer-dist laravel/laravel blog
I am trying to install Laravel and start a project using composer but getting the following error
OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
When I run composer diagnose getting below result
PS C:xampphtdocswebstore_services> composer diagnose
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: Warning: Accessing 192.168.1xx.2xx over http which is an insecure protocol.
OK
Checking https connectivity to packagist: [ComposerDownloaderTransportException] The "https://repo.packagist.org/packages.json" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Failed to enable crypto
failed to open stream: operation failed
Checking github.com rate limit: FAIL
[ComposerDownloaderTransportException] The "https://api.github.com/rate_limit" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Failed to enable crypto
failed to open stream: operation failed
Checking disk free space: OK
Checking pubkeys:
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0 87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B 0C708369 153E328C AD90147D AFE50952
OK
Checking composer version:
[ComposerDownloaderTransportException]
The "https://getcomposer.org/versions" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Failed to enable crypto
failed to open stream: operation failed
diagnose
I have tried almost every solution on the Internet
php -r "print_r(openssl_get_cert_locations());"
Result
(
[default_cert_file] => C:usrlocalssl/cert.pem
[default_cert_file_env] => SSL_CERT_FILE
[default_cert_dir] => C:usrlocalssl/certs
[default_cert_dir_env] => SSL_CERT_DIR
[default_private_dir] => C:usrlocalssl/private
[default_default_cert_area] => C:usrlocalssl
[ini_cafile] => C:xamppphpcacert.pem
[ini_capath] => C:xamppphpcacert.pem
)
How will I change the location of default_cert_file in this, Only this is left?
Since I am on Corporate Proxy I have set the env-variable of the proxy.
https_proxy : http://user:pass@host:port
http_proxy : http://user:pass@host:port
After everything I do, it doesn’t help me though.
-
jimmyp82
- OpenVpn Newbie
- Posts: 3
- Joined: Wed Jun 30, 2021 10:44 am
OpenSSL error:1416F086 tls_process_server_certificate:certificate verify failed
Hello
New to this forum and very new to openvpn. I have inherited a setup so am trying to get my head around it. We have a user which is having an issue connecting. Below is the log from the user.
Prior to this he was getting a different error about the certificate having expired.
I found that the client cert was still valid however the ca.crt and the gateway.crt on the server were both out of date. I used this command —
Code: Select all
openssl x509 -in ca.crt -days 36500 -out ca_new.crt -signkey ca.keyto sign a new ca.crt and a gateway.crt which I replaced, ie renamed the old crt and put the new ca.crt in place. I also sent the user the updated ca.crt.
After having done that however the user now gets the error below —
Code: Select all
Wed Jun 30 11:30:07 2021 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Wed Jun 30 11:30:07 2021 MANAGEMENT: >STATE:1625045407,RESOLVE,,,,,,
Wed Jun 30 11:30:07 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]XXXXXXXXX:XXXX
Wed Jun 30 11:30:07 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Jun 30 11:30:07 2021 Attempting to establish TCP connection with [AF_INET]XXXXXXXXX:XXXX [nonblock]
Wed Jun 30 11:30:07 2021 MANAGEMENT: >STATE:1625045407,TCP_CONNECT,,,,,,
Wed Jun 30 11:30:08 2021 TCP connection established with [AF_INET]XXXXXXXXX:XXXX
Wed Jun 30 11:30:08 2021 TCP_CLIENT link local: (not bound)
Wed Jun 30 11:30:08 2021 TCP_CLIENT link remote: [AF_INET]XXXXXXXXX:XXXX
Wed Jun 30 11:30:08 2021 MANAGEMENT: >STATE:1625045408,WAIT,,,,,,
Wed Jun 30 11:30:09 2021 MANAGEMENT: >STATE:1625045409,AUTH,,,,,,
Wed Jun 30 11:30:09 2021 TLS: Initial packet from [AF_INET]XXXXXXXXX:XXXX, sid=4b062365 dc720dc0
Wed Jun 30 11:30:09 2021 VERIFY OK: depth=1, C=UK, ST=UK, L=London, O=XXXXXXXXX, CN=gateway, emailAddress=XXXXXXXXX
Wed Jun 30 11:30:09 2021 VERIFY ERROR: depth=0, error=certificate signature failure: C=UK, ST=UK, L=London, O=XXXXXXX, CN=gateway, emailAddress=XXXXXXXXXXX
Wed Jun 30 11:30:09 2021 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Wed Jun 30 11:30:09 2021 TLS_ERROR: BIO read tls_read_plaintext error
Wed Jun 30 11:30:09 2021 TLS Error: TLS object -> incoming plaintext read error
Wed Jun 30 11:30:09 2021 TLS Error: TLS handshake failed
Wed Jun 30 11:30:09 2021 Fatal TLS error (check_tls_errors_co), restarting
Wed Jun 30 11:30:09 2021 SIGUSR1[soft,tls-error] received, process restarting
Wed Jun 30 11:30:09 2021 MANAGEMENT: >STATE:1625045409,RECONNECTING,tls-error,,,,,
Wed Jun 30 11:30:09 2021 Restart pause, 5 second(s)Any help much appreciated!
Thanks
James
-
jimmyp82
- OpenVpn Newbie
- Posts: 3
- Joined: Wed Jun 30, 2021 10:44 am
Re: OpenSSL error:1416F086 tls_process_server_certificate:certificate verify failed
Post
by jimmyp82 » Thu Jul 01, 2021 8:48 am
Hello
Thanks for the reply!
So you mean everything has to be recreated again, ie CA and gateway and client crts and the keys as well?
Thanks
-
300000
- OpenVPN Expert
- Posts: 688
- Joined: Tue May 01, 2012 9:30 pm
Re: OpenSSL error:1416F086 tls_process_server_certificate:certificate verify failed
Post
by 300000 » Thu Jul 01, 2021 10:58 am
If you create new CA key so you need create new client key too . nothing you can do or there is nothing about renew certificate . what do you expect now? do it again on 10 years time then do it again . every 10 years you need to do this .
-
openvpn_inc
- OpenVPN Inc.
- Posts: 1137
- Joined: Tue Feb 16, 2021 10:41 am
Re: OpenSSL error:1416F086 tls_process_server_certificate:certificate verify failed
Post
by openvpn_inc » Thu Jul 01, 2021 3:36 pm
300000 wrote: ↑
Thu Jul 01, 2021 10:58 am
If you create new CA key so you need create new client key too . nothing you can do or there is nothing about renew certificate . what do you expect now? do it again on 10 years time then do it again . every 10 years you need to do this .
10 years is just long enough to forget how to do it. 
Strictly speaking, a new CA certificate means you need a new set of certificates, not keys. Existing keys (CA, server and clients) can generate new CSRs (certificate signing requests) to be signed by the CA and create the new certificates.
If the CA is creating the keys for the users, this distinction might not be important to you. But when my own 10-year CA cert expired I kept the same keys.
Regards, rob0
OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support
-
TinCanTech
- OpenVPN Protagonist
- Posts: 11142
- Joined: Fri Jun 03, 2016 1:17 pm
Re: OpenSSL error:1416F086 tls_process_server_certificate:certificate verify failed
Post
by TinCanTech » Thu Jul 01, 2021 4:46 pm
openvpn_inc wrote: ↑
Thu Jul 01, 2021 3:36 pm
when my own 10-year CA cert expired I kept the same keys
That is fine for you but is probably not a good idea for most average users.
It is not documented by any openvpn articles that I’ve seen and even Easy-RSA does not have anything solid to follow ..
-
jimmyp82
- OpenVpn Newbie
- Posts: 3
- Joined: Wed Jun 30, 2021 10:44 am
Re: OpenSSL error:1416F086 tls_process_server_certificate:certificate verify failed
Post
by jimmyp82 » Fri Jul 02, 2021 12:05 pm
Hello
I got a bit further, now testing with a new client i have setup on a laptop however getting this —
Fri Jul 02 04:59:12 2021 WARNING: —ns-cert-type is DEPRECATED. Use —remote-cert-tls instead.
Fri Jul 02 04:59:12 2021 MANAGEMENT: >STATE:1625227152,RESOLVE,,,,,,
Fri Jul 02 04:59:12 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XX:1194
Fri Jul 02 04:59:12 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Jul 02 04:59:12 2021 Attempting to establish TCP connection with [AF_INET]XXX.XXX.XXX.XX:1194 [nonblock]
Fri Jul 02 04:59:12 2021 MANAGEMENT: >STATE:1625227152,TCP_CONNECT,,,,,,
Fri Jul 02 05:01:13 2021 TCP: connect to [AF_INET]XXX.XXX.XXX.XX1194 failed: Unknown error
Fri Jul 02 05:01:13 2021 SIGUSR1[connection failed(soft),init_instance] received, process restarting
Fri Jul 02 05:01:13 2021 MANAGEMENT: >STATE:1625227273,RECONNECTING,init_instance,,,,,
Fri Jul 02 05:01:13 2021 Restart pause, 5 second(s)
Fri Jul 02 05:01:18 2021 WARNING: —ns-cert-type is DEPRECATED. Use —remote-cert-tls instead.
Fri Jul 02 05:01:18 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XX:1194
Fri Jul 02 05:01:18 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Jul 02 05:01:18 2021 Attempting to establish TCP connection with [AF_INET]XXX.XXX.XXX.XX:1194 [nonblock]
Fri Jul 02 05:01:18 2021 MANAGEMENT: >STATE:1625227278,TCP_CONNECT,,,,,,
-
openvpn_inc
- OpenVPN Inc.
- Posts: 1137
- Joined: Tue Feb 16, 2021 10:41 am
Re: OpenSSL error:1416F086 tls_process_server_certificate:certificate verify failed
Post
by openvpn_inc » Sat Jul 03, 2021 1:19 pm
jimmyp82 wrote: ↑
Fri Jul 02, 2021 12:05 pm
HelloI got a bit further, now testing with a new client i have setup on a laptop however getting this —
Fri Jul 02 04:59:12 2021 WARNING: —ns-cert-type is DEPRECATED. Use —remote-cert-tls instead.
Fix this, that should be easy enough to do, see the manual and look for «—remote-cert-tls«.
jimmyp82 wrote: ↑
Fri Jul 02, 2021 12:05 pm
Fri Jul 02 04:59:12 2021 MANAGEMENT: >STATE:1625227152,RESOLVE,,,,,,
Fri Jul 02 04:59:12 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XX:1194
Fri Jul 02 04:59:12 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Jul 02 04:59:12 2021 Attempting to establish TCP connection with [AF_INET]XXX.XXX.XXX.XX:1194 [nonblock]
Fri Jul 02 04:59:12 2021 MANAGEMENT: >STATE:1625227152,TCP_CONNECT,,,,,,
Fri Jul 02 05:01:13 2021 TCP: connect to [AF_INET]XXX.XXX.XXX.XX1194 failed: Unknown error
Here you have a TCP connection failing for an unknown reason. It’s unfortunate that more information could not be logged, but openvpn simply could not determine the actual failure. If the connection is not established, the problem almost surely lies outside of openvpn.
Our IRC channel /topic says, «The problem is your firewall, really.» That’s the chief suspect here, and note that it could be a firewall anywhere along the way between (or on client and server. Look at other tools like tcpdump(1) to see more about what the problem might be. Your nc(1) or netcat(1) utility can help you test.
I should add, TCP is generally not recommended for openvpn. It should normally only be used when getting through silly firewalls that you don’t control. Packet loss of a TCP stream inside another TCP stream rapidly snowballs into more and more packets being repeated at both levels. UDP is ideal for things like this.
I hope this helps, good luck. Regards, rob0
OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support
The certificate was created with EFF’s certbot.
openssl verify -CAfile ca.pem server-cert.pem
server-cert.pem: OK
No client certificate was created nor is used.
Remote check is also successful ([..] means redacted):
openssl s_client -starttls mysql -connect srv.addr.tld:3306 -tls1_2
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = srv.addr.tld
verify return:1
---
Certificate chain
0 s:CN = srv.addr.tld
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
[..]
-----END CERTIFICATE-----
subject=CN = srv.addr.tld
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+S
HA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:DSA+SHA256:DSA+SHA384:DSA+SHA512
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA25
6:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:DSA+SHA256:DSA+SHA384:DSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3926 bytes and written 356 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: [..]
Session-ID-ctx:
Master-Key: [..]
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - [..]
0010 - [..]
0020 - [..]
0030 - [..]
0040 - [..]
0050 - [..]
0060 - [..]
0070 - [..]
0080 - [..]
0090 - [..]
00a0 - [..]
Start Time: 1586808968
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
read:errno=104
I am new on this board. I also posted the issue in the CraftCMS-board, but I think it is more related to this one. I hope it fits in here.
I found some similar posts here, but unfortunately, but none solved my problem. Be assured that I searched quite a lot (for hours) but could not solve it. I hope I have not overlooked a good answer.
This post is somewhat long — I am sorry — but I did want to include some debugging-information since I guess it might be helpful in finding a solution.
Thank you very much for taking the time to read and (hopefully) respond.
Summary: I tried to send mails (from a php script) via smtp. The site uses an external mailserver (MX mail.domain.com → mailgate.otherdomain.com → A to external IP). When trying to send the mail, I get an error: SSL routines:tls_process_server_certificate:certificate verify failed. Trying to connect via SSH results in Verification error: self signed certificate which is true for the webserver, but not for the external mailserver. CheckTLS states: Cert Hostname DOES NOT VERIFY (mailgate.wwwshort.com != localhost.localdomain). I am in charge of the webserver (managed server) but not of the mailserver (externally provided).
The Setup
Website runs on wwwdomain.com — they also have a shorter version, let’s call it wwwshort.com
Mail server is provided by another company and is found on mailgate.wwwshort.com (this is the MX for all (wwwdomain, wwwshort, other domains) the domains. In the DNS for wwwshort.com there is an A record pointing to the IP). There is also an A record mail.* pointing to mailgate.wwwshort.com.
I try to send emails from a craftcms3 installation via smtp. Mailserver is mail.wwwdomain.com
All domains have self-signed certificates. The server behind mailgate.shortdomain.com has a proper SSL certificate which also mentions all the possible domain names (e.g. mail.wwwdomain.com, mail.wwwshort.com, mailgate.wwwshort.com etc).
My client uses this mailserver daily (I guess it is an Microsoft Exchange Server) and has no problems whatsoever.
The Problem
When trying to send mails, I get the following error in my log:
Error sending email: stream_socket_enable_crypto(): SSL operation
failed with code 1. OpenSSL Error messages: error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify faile
I was able (some time ago) to perform the workaround suggested here but I don’t want to do that anymore since it is not really secure.
Troubleshooting
I set up a script using PHPMailer to get a more complete log. This was what I got:
2021-01-23 18:30:30 Connection: opening to mail.wwwdomain.com:587, timeout=300, options=array()
2021-01-23 18:30:30 Connection: opened
2021-01-23 18:30:30 SMTP INBOUND: "220 mailgate.wwwshort.com ESMTP - DSS"
2021-01-23 18:30:30 SERVER -> CLIENT: 220 mailgate.wwwshort.com ESMTP - DSS
2021-01-23 18:30:30 CLIENT -> SERVER: EHLO www.wwwdomain.com
2021-01-23 18:30:30 SMTP INBOUND: "250-mailgate.wwwshort.com"
2021-01-23 18:30:30 SMTP INBOUND: "250-PIPELINING"
2021-01-23 18:30:30 SMTP INBOUND: "250-SIZE 105080012"
2021-01-23 18:30:30 SMTP INBOUND: "250-ETRN"
2021-01-23 18:30:30 SMTP INBOUND: "250-STARTTLS"
2021-01-23 18:30:30 SMTP INBOUND: "250-ENHANCEDSTATUSCODES"
2021-01-23 18:30:30 SMTP INBOUND: "250-8BITMIME"
2021-01-23 18:30:30 SMTP INBOUND: "250 DSN"
2021-01-23 18:30:30 SERVER -> CLIENT: 250-mailgate.wwwshort.com250-PIPELINING250-SIZE 105080012250-ETRN250-STARTTLS250-ENHANCEDSTATUSCODES250-8BITMIME250 DSN
2021-01-23 18:30:30 CLIENT -> SERVER: STARTTLS
2021-01-23 18:30:30 SMTP INBOUND: "220 2.0.0 Ready to start TLS"
2021-01-23 18:30:30 SERVER -> CLIENT: 220 2.0.0 Ready to start TLS
2021-01-23 18:30:30 Connection failed. Error #2: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed [/usr/www/users/client/test-mail/PHPMailer/SMTP.php line 467]
SMTP Error: Could not connect to SMTP host.
2021-01-23 18:30:30 CLIENT -> SERVER: QUIT
2021-01-23 18:30:30
2021-01-23 18:30:30
2021-01-23 18:30:30
2021-01-23 18:30:30
2021-01-23 18:30:30
2021-01-23 18:30:30 Connection: closed
SMTP Error: Could not connect to SMTP host.
Message could not be sent. Mailer Error: SMTP Error: Could not connect to SMTP host.
Now I searched the web and did a lot of investigations. I will list the results here.
Checking CA certificates
I followed the advice from PHPMailer and checked the CA certs by
echo QUIT | openssl s_client -crlf -starttls smtp -CAfile /etc/ssl/cacert.pem -connect smtp.gmail.com:587
This worked perfectly fine.
Now I tried the same with mail.wwwdomain.com:
echo QUIT | openssl s_client -crlf -starttls smtp -CAfile /etc/ssl/cacert.pem -connect mail.wwwdomain.com:587
Here the problem started again:
CONNECTED(00000003)
depth=0 O = NA, CN = localhost.localdomain
verify error:num=18:self signed certificate
verify return:1
depth=0 O = NA, CN = localhost.localdomain
verify return:1
---
Certificate chain
0 s:O = NA, CN = localhost.localdomain
i:O = NA, CN = localhost.localdomain
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFMDCCAxigJANm1uWBG8V5qMA0GIb3DQEBDAUAMC0xCzAJBgNV
BAoMAk5BMR4wHAYDDBVQub2WjAtMQswCQYDVQAJOQMBwGA1UEAww
bG9jYWxob3N0LmxvY2FsZG9tYWluMIICIjANBgkqhk0BAg8AMIIC (shortened)
CgKCAgEAyXZvXtT7f
-----END CERTIFICATE-----
subject=O = NA, CN = localhost.localdomain
issuer=O = NA, CN = localhost.localdomain
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2481 bytes and written 483 bytes
Verification error: self signed certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 0225B94178B4DE0B4499DAFB0C0D3AD4BE5519CCFBA4458E1333FF56B56D700D
Session-ID-ctx:
Master-Key: 103159001B6597C40E8C35A31B5DC240AE52D081BEE153A0B904A71C618D235AE5DD21192A784FBD35084130A1A36688
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 71 f2 0b 8f 85 4b e2 9a-cb bc 21 1f 5a c6 a7 b4 q....K....!.Z...
(shortened)
Start Time: 1611427542
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
Extended master secret: yes
---
250 DSN
DONE
The output was equal for mailgate.wwwshort.com and the IP-Adress of the Mailserver.
Two things caught my attention:
SSL handshake has read 2481 bytes and written 483 bytes
Verification error: self signed certificate
and the mentioning of localhost.local
0 s:O = NA, CN = localhost.localdomain
i:O = NA, CN = localhost.localdomain
SSL Report
I used the SSL Report from SSL Labs to test the domains.
wwwlong.comwas correctly recognized as «self-signed» and lists only the main domain and www.* It got an B rating.wwwshort.comalsomail.wwwdomain.comwas correctly recognized as not-self-signed and listed as «alternative names» all the other possible domains pointing to this server. It got an A+ rating.
Check-TLS
I used CheckTLS to run some tests on wwwdomain.com. It identified the MX server correctly as mailgate.wwwshort.com (with correct IP) and showed the following output.
[000.000] Trying TLS on mailgate.wwwshort.com[217.86.144.15:25] (10)
[000.099] Server answered
[000.595] <‑‑ 220 mailgate.wwwshort.com ESMTP - DSS
[000.595] We are allowed to connect
[000.595] ‑‑> EHLO www12-do.checktls.com
[000.691] <‑‑ 250-mailgate.wwwshort.com
250-PIPELINING
250-SIZE 105080012
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
[000.691] We can use this server
[000.691] TLS is an option on this server
[000.692] ‑‑> STARTTLS
[000.788] <‑‑ 220 2.0.0 Ready to start TLS
[000.788] STARTTLS command works on this server
[001.010] Connection converted to SSL
SSLVersion in use: TLSv1_2
Cipher in use: ECDHE-RSA-AES256-GCM-SHA384
Perfect Forward Secrecy: yes
Certificate #1 of 1 (sent by MX):
Cert VALIDATION ERROR(S): self signed certificate
So email is encrypted but the recipient domain is not verified
Cert Hostname DOES NOT VERIFY (mailgate.wwwshort.com != localhost.localdomain)
So email is encrypted but the host is not verified
Not Valid Before: Jan 9 20:31:46 2021 GMT
Not Valid After: Oct 6 20:31:46 2023 GMT
subject= /O=NA/CN=localhost.localdomain
issuer= /O=NA/CN=localhost.localdomain
[001.013] ~~> EHLO www12-do.checktls.com
[001.111] <~~ 250-mailgate.wwwshort.com
250-PIPELINING
250-SIZE 105080012
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
[001.111] TLS successfully started on this server
[001.111] ~~> MAIL FROM:<test@checktls.com>
[001.212] <~~ 250 2.1.0 Ok
[001.212] Sender is OK
[001.212] ~~> QUIT
[001.311] <~~ 221 2.0.0 Bye
Highlighted was this part:
Certificate #1 of 1 (sent by MX):
Cert VALIDATION ERROR(S): self signed certificate
So email is encrypted but the recipient domain is not verified
Cert Hostname DOES NOT VERIFY (mailgate.wwwshort.com != localhost.localdomain)
So email is encrypted but the host is not verified
I wondered whether the self-signed certificate of the webserver caused the problem (since it was a wildcard *.wwwdomain.com initially) so I replaced all the certificates with self-signed ones that only include the main domain. However, the problem persists (although I am not sure whether I just have to wait longer).
My «not-understanding»
To my (not)understanding there are reports on two problems: 1) the certificate is self signed (which is true for the webserver,but not for the mailserver) and 2) the domain names don’t match up.
I am absolutely not an expert on all this. Can anyone tell me whether the problem is on my side (webserver, craft, etc.) or on «their side» (mailserver).
I realized, after posting the below comment under the author’s question, it may prove helpful to offer the code required to generate the server and client certs properly with the correct EKUs.
-
Removing the EKU requirement is a bad idea all around and undermines the security of the VPN — it is not advised under any circumstance. If the «people running our VPN server» is a 3rd party, find another vendor, as they clearly don’t understand what they’re doing. If the individuals are in your company, address it directly with them to properly configure the VPN server, as they also don’t understand what they’re doing. The EKU in question prevents MITM attacks. Please see extendedKeyUsage section in this answer for the EKU definitions
I cover V3 Profiles, KUs, and EKUs within the openssl.cnf in more depth within this answer
VPN Server:
[ v3_vpn_server ]
basicConstraints = critical, CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer:always
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
extendedKeyUsage = critical, serverAuth
subjectAltName = @alt_vpn_server
keyUsage:nonRepudiation: Prevents signing entity from falsely denying some actiondigitalSignature: Used for entity and data origin authentication with integrityThe following two KUs allows use of all ciphers:
Choosing one or the other, and not both, limits the ciphers the server can utilizekeyEncipherment: Used to encrypt symmetric key, which is then transferred to targetkeyAgreement: Enables use of key agreement to establish symmetric key with target
extendedKeuUsage:serverAuth: Server authentication, distinguishing a server clients authenticate against
Required KUs:digitalSignature,keyEnciphermentorkeyAgreement
VPN Client:
[ v3_vpn_client ]
basicConstraints = critical, CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer:always
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = critical, clientAuth
subjectAltName = @alt_vpn_client
extendedKeuUsage:clientAuth: Client authentication, distinguishing a client as a client only
Required KUs:digitalSignatureand/orkeyAgreement