设置自己的证书颁发机构(CA)

总览

建立OpenVPN 2.x配置的第一步是建立PKI(公钥基础结构)。PKI包括:

服务器和客户端都对彼此进行身份验证是通过如下方式:

从VPN角度来看,此安全模型具有许多理想的功能:
desirable features 理想的功能
只有由主CA签名的客户端证书(我们将在下面生成),服务器才接受.而且由于服务器可以执行此签名验证而无需访问CA私钥本身,因此CA密钥(整个PKI中最敏感的密钥)有可能驻留在完全不同的计算机上,甚至没有网络连接的计算机也可以驻留。 The server will only accept clients whose certificates were signed by the master CA certificate (which we will generate below). And because the server can perform this signature verification without needing access to the CA private key itself, it is possible for the CA key (the most sensitive key in the entire PKI) to reside on a completely different machine, even one without a network connection.

请注意,服务器和客户端时钟需要大致同步,否则证书可能无法正常工作。

生成主证书颁发机构(CA)证书和密钥

在本部分中,我们将为三个单独的客户端生成一个主CA证书/密钥,一个服务器证书/密钥以及证书/密钥。

For PKI management, we will use easy-rsa 2, a set of scripts which is bundled with OpenVPN 2.2.x and earlier. If you’re using OpenVPN 2.3.x, you need to download easy-rsa 2 separately from here.
init-config

现在,编辑 vars 文件( 在Windows上称为 vars.bat)并设置KEY_COUNTRY,KEY_PROVINCE,KEY_CITY,KEY_ORG和KEY_EMAIL参数。请勿将任何这些参数留空。

接下来,初始化PKI。

. ./vars
./clean-all
./build-ca

在Windows上:

vars
clean-all
build-ca

最终的命令(build-ca)将通过调用交互式openssl命令来构建证书颁发机构(CA)证书和密钥 :

ai:easy-rsa # ./build-ca
Generating a 1024 bit RSA private key
............++++++
...........++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [KG]:
State or Province Name (full name) [NA]:
Locality Name (eg, city) [BISHKEK]:
Organization Name (eg, company) [OpenVPN-TEST]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:OpenVPN-CA
Email Address [me@myhost.mydomain]:

请注意,按照上述顺序,大多数查询的参数默认为vars或 vars.bat 文件中设置的值 。必须明确输入的唯一参数是”Common Name”。在上面的示例中,我使用了”OpenVPN-CA”。

生成服务器的证书和密钥

接下来,我们将为服务器生成证书和私钥。在Linux / BSD / Unix上:

./build-key-server server

在Windows上:

build-key-server server

与上一步一样,大多数参数都可以默认设置。当查询”Common Name”时,输入“server”。另外两个查询需要肯定的答复:

Sign the certificate? [y/n]

1 out of 1 certificate requests certified, commit? [y/n]

为3个客户端生成证书和密钥 生成客户端证书与上一步非常相似。在Linux / BSD / Unix上:

./build-key client1
./build-key client2
./build-key client3

在Windows上:

build-key client1
build-key client2
build-key client3

如果要用密码保护客户端密钥,请替换 build-key-pass 脚本。

请记住,对于每个客户端,请确保 在出现提示时键入适当的 公用名,即“ client1”,“ client2”或“ client3”。始终为每个客户端使用唯一的通用名称。

生成Diffie Hellman参数

必须为OpenVPN服务器生成Diffie Hellman参数。在Linux / BSD / Unix上:

./build-dh

在Windows上:

build-dh

输出:

ai:easy-rsa # ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
.................+...........................................
...................+.............+.................+.........
......................................

密钥文件

现在,我们将在keys 子目录中找到我们新生成的密钥和证书。这是有关文件的说明:

文件名 需要者 目的 保密
ca.crt 服务器+所有客户端 根CA证书 没有
ca.key 仅限密钥签名机 根CA密钥
dh{n}.pem 仅服务器 Diffie Hellman参数 没有
server.crt 仅服务器 服务器密钥 没有
server.key 仅服务器 服务器密钥
client1.crt 仅client1 Client1证书 没有
client1.key 仅client1 Client1密钥
client2.crt 仅client2 Client2证书 没有
client2.key 仅client2 Client2密钥
client3.crt 仅client3 Client3证书 没有
client3.key 仅client3 Client3密钥

密钥生成过程的最后一步是将所有文件复制到需要它们的计算机上,并注意通过安全通道复制机密文件。

但是,您可能会说。在没有预先存在的安全通道的情况下,是否可以设置PKI?

答案明显上是可以的。出于简洁起见,在上面的示例中,我们在同一位置生成了所有私钥。我们如果再多花点心思,可以做些不同的选择。例如,我们可以让客户端在本地生成自己的私钥,而不是在服务器上生成客户端证书和密钥,然后将证书签名请求(CSR)提交给`密钥签名计算机`。反过来,`密钥签名机`可能已经处理了CSR,并将签名的证书返回给客户端。可以完成此操作,而无需密秘的 .key 文件离开生成它的计算机的硬盘驱动器。 The answer is ostensibly yes. In the example above, for the sake of brevity, we generated all private keys in the same place. With a bit more effort, we could have done this differently. For example, instead of generating the client certificate and keys on the server, we could have had the client generate its own private key locally, and then submit a Certificate Signing Request (CSR) to the key-signing machine. In turn, the key-signing machine could have processed the CSR and returned a signed certificate to the client. This could have been done without ever requiring that a secret .key file leave the hard drive of the machine on which it was generated.