I encountered a practical need today, and finally decided to map the test server on a virtual machine on a remote intranet to the public network. I thought of using OpenVPN to do this many years ago, so I looked at http:/ /flashing.iteye.com/blog/575402 Previous articles, just do as they say, and the result is a sad discovery...things changed~
In fact, the main reason is that Centos 7 removed Openssl's MD5 support (I listened to various complaints about centos7 for a year, but I didn't actually use it, and it fell into the pit immediately), but windows/ubuntu (using 14.04LTS test ), openssl still uses md5 as the hash algorithm by default and can correctly identify the md5 hash algorithm, so it is a tragedy, only cenots7 is not easy to use. The point is that this mistake is a big mistake that is covered up by a small mistake, so it's hard to find.
wrong keyword:
A: VERIFY ERROR: depth=1, error=certificate is not yet valid
or error 9 at 1 depth lookup:certificate is not yet valid
B: VERIFY ERROR: depth=0, error=certificate signature failure
C: error 7 at 0 depth lookup:certificate signature failure
Install these first:
sudo yum update
sudo yum install -y wget ntp ntpdate openvpn easy-rsa bridge-utils
Solution A:
First of all, error A is because the timezone is not set correctly and the time is not proofread when centos7 is installed by default (no desktop), so the server time has not yet reached the signature time of the certificate, so you need to re-set the timezone and proofread the time:
sudo timedatectl set-timezone Asia/Shanghai
sudo ntpdate time.windows.com&
sudo systemctl enable ntpd
sudo systemctl start ntpd
sudo timedatectl set-ntp true
Then execute the date command to see if the time is correct, execute timedatectl to see if the set time zone and other information are correct, and whether ntp is enabled.
Local time: Thu 2015-10-15 12:37:25 CST
Universal time: Thu 2015-10-15 04:37:25 UTC
Timezone: Asia/Shanghai (CST, +0800)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
For B and C, there are two problems to be solved.
The first is that the Common Name when generating the certificate cannot be repeated. The common name of ca, server and each client must be unique. Although the verification is a matter of openssl, it may be repeated in most cases. question, but still not recommended to repeat.
Whatever method you use to generate the certificate and key files, the Common Name value used for the server and client certificates/keys must each differ from the Common Name value used for the CA certificate. Otherwise, the certificate and key files will not work for servers compiled using OpenSSL.
The second is the final problem, that is, openssl under centos7 does not support md5, and the verification can be done by the following command:
openssl verify -CAfile ca.crt -purpose sslclient weblogic.crt
Or directly
openssl verify -CAfile ca.crt weblogic.crt
The server is of course
openssl verify -CAfile ca.crt -purpose sslserver server.crt
, you can see that OK can be successfully displayed under windows/ubuntu, and centos 7 reports an error. This is the openvpn report:
error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm:a_verify.c:179: The source of the error.
There are still two ways to solve the problem. The first is to open the support of openssl under centos7 for md5 through environment variables:
However, I did not succeed in doing so, mainly if it is in the shell, after adding the environment variable to su,
sudo openvpn --config /etc/openvpn/client.ovpn
It can be successful, the reason is that these are all root variables, but the service mode of centos7 (7.1), which is added to NetworkManager according to the original text, does not take effect, and the reason is unknown.
Considering that this situation is mainly due to the fact that there have been multiple certificates before, it is necessary to carefully consider compatibility. In my case, the certificate is reissued, so I decided to give up research on this branch, no longer use md5, and use other hashing algorithms to generate new ones. Certificate.
Because I'm not familiar with openssl, and I don't know where to set the md algorithm easy-rsa to recognize it. I happened to find a diff of a patch on github, and then I realized that it was set in openssl.cnf.
cenots is under /usr/share/easy-rsa/2.0/, windows is in the openvpn directory, put the contents of openssl-1.0.0.cnf in windows
default_md = md5 # use public key default MD
change to
default_md = sha256 # use public key default MD
I took a look at the default setting of easy-rsa of centos, which is also sha256, which is relieved.
Then all the certificates are newly generated, put under centos and tested, and they work well. After successful dialing, ifconfig can see that there is a tap0 device.
Attachment 1: Several reference URLs for installation, some are useful and some are useless (in fact, it is not troublesome to operate according to the readme.txt under easy-rsa, of course, you need to change the variable settings of vars):
http://flashing.iteye.com/blog/575402
http://www.cnblogs.com/szzchristy/p/3491757.html
https://www.digitalocean.com/community/tutorials/how-to-setup-and-configure-an-openvpn-server-on-centos-7
http://www.server-world.info/en/note?os=CentOS_6&p=openvpn
Attachment 2: Start openvpn under centos 7 linux
Copy client.ovpn (or server.opvn, I am a linux client here, so I named it client.ovpn), ca.crt, client certificate crt file and key file to /etc/openvpn
sudo openvpn --config /etc/openvpn/client.ovpn
Can be connected directly for use as a test, and if successful, can be installed as a service
First copy /etc/openvpn/client.ovpn to /etc/openvpn/client.conf
sudo systemctl enable [email protected]
sudo systemctl start [email protected]
Here @ refers to the corresponding conf file name under /etc/openvpn
Of course stopping and unregistering the service is
sudo systemctl stop [email protected]
sudo systemctl disable [email protected] to
view the service status is
sudo systemctl status [email protected]