Взято с https://wiki.nix-pro.com Там еще много интересного.
cd && mkdir -p myCA/signedcerts && mkdir myCA/private && cd myCA
Предназначение подкаталогов, и их содержимое выглядит следующим образом: <html> <br> ~/myCA : содержит CA сертификат, базу данных сертификатов, сгенерированные сертификаты, ключи и CSR<br> ~/myCA/signedcerts : содержит копии всех подписанных сертификатов<br> ~/myCA/private : содержит секретный ключ<br> </html>
echo '01' > serial && touch index.txt
В файле serial записывается текущий серийный номер подписываемого сертификата в шестнадцатиричном формате. В файл index.txt сохраняются данные о подписываемых сертификатах.
vim ~/myCA/caconfig.cnf
# Default configuration to use when one is not provided on the command line.
#
[ ca ]
# Use local_ca policy to sign certificates
default_ca = local_ca
# Paths to files and directories needed to create certificates
[ local_ca ]
dir = /home/<username>/myCA
certificate = $dir/cacert.pem
database = $dir/index.txt
new_certs_dir = $dir/signedcerts
private_key = $dir/private/cakey.pem
serial = $dir/serial
#
# Default expiration and encryption policies for certificates.
#
default_crl_days = 365
# A CRL is a Certificate Revocation List. When you issue a cert for say, 365
# days, its useful to have a method whereby you can revoke its validity before
# it expires. For example, if it is compromised (password stolen, etc). So the
# Cerificate Authority (you in this case) issues a Revocation List periodically
# listing which certs have been revoked.
#
# The client application doesn't want to have to look for a new list every time
# it validates a cert so each Revocation list has an expiry date. The 'default_crl_days'
# param in the config file just specifies the default lifetime of any CRLs you might
# issue if you don't set an explicit expiry date
default_days = 365
default_md = md5
#
policy = local_ca_policy
x509_extensions = local_ca_extensions
#
# Default policy to use when generating server certificates. The following
# fields must be defined in the server certificate.
#
[ local_ca_policy ]
commonName = supplied
stateOrProvinceName = supplied
countryName = supplied
emailAddress = supplied
organizationName = supplied
organizationalUnitName = supplied
#
# x509 extensions to use when generating server certificates.
#
[ local_ca_extensions ]
#subjectAltName = DNS:alt.example.com
#
# When making a SSL/TLS connection the client requests a digital certificate from the server;
# once the server sends the certificate, the client examines it and compares the name it was trying
# to connect to with the name(s) included in the certificate. If a match is found the connection
# proceeds as normal. If a match is not found the user may be warned of the discrepancy and the
# connection may be aborted as the mismatch may indicate an attempted man-in-the-middle attack.
# It is possible for one certificate to cover multiple names. The X.509 v3 specification introduced
# the so-called subjectAltName field which allows one certificate to specify more than one domain and
# it is possible to have wildcards in both the common name and subjectAltName fields. However it may be
# impractical to obtain a single certificate that covers all names a server will be responsible for.
basicConstraints=CA:FALSE
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
#nsCertType = server
# this option is required only if OpenVPN is running with ns-cert-type check
#
# ns-cert-type OpenVPN option Requires that peer certificate was signed
# with an explicit nsCertType designation of "client" or "server".
# This is a useful security option for clients, to ensure that the host
# they connect with is a designated server.
#
# If the server certificate's nsCertType field is set to "server", then
# the clients can verify this with --ns-cert-type server.
#
# This is an important security precaution to protect against a man-in-the-middle
# attack where an authorized client attempts to connect to another client by impersonating
# the server. The attack is easily prevented by having clients verify the server
# certificate using any one of --ns-cert-type, --tls-remote, or --tls-verify.
#
# The default root certificate generation policy.
#
[ req ]
default_bits = 2048
default_keyfile = /home/<username>/myCA/private/cakey.pem
default_md = md5
#
prompt = no
distinguished_name = root_ca_distinguished_name
x509_extensions = root_ca_extensions
# Root Certificate Authority distinguished name. Change these fields to match
# your local environment!
#
[ root_ca_distinguished_name ]
commonName = MyOwn Root Certificate Authority
stateOrProvinceName = NC
countryName = US
localityName = Asheville
emailAddress = root@example.com
organizationName = My Own Company
organizationalUnitName = IT Department
#
[ root_ca_extensions ]
basicConstraints = CA:true
chmod go-rwx private
openssl req -batch -nodes -config ~/myCA/caconfig.cnf -x509 -newkey rsa:2048 -out cacert.pem -outform PEM -days 365
openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 500 \ -subj /C=US/ST=NC/L=Asheville/O=My\ Own\ Company/OU=IT\ Department/CN=MyOwn\ Root\ Certificate\ Authority/emailAddress=root@root@example.com \ -out ca.crt
В результате выполнения команды появятся два файла ca.key и ca.crt. Просмотреть данные закрытого ключа и сертификата вы можете с помощью команд:
openssl rsa -noout -text -in ca.key (для ключа) openssl x509 -noout -text -in ca.crt (для сертификата)
Описание аргументов: <html> req - Запрос на создание нового сертификата.<br> -new - Создание запроса на сертификат (Certificate Signing Request - CSR).<br> -newkey rsa:1024 - Автоматически будет создан новый закрытый RSA ключ длиной 1024 бита. Длину ключа можете настроить по своему усмотрению.<br> -nodes - Не шифровать закрытый ключ (См. примечание выше).<br> -keyout ca.key - Закрытый ключ сохранить в файл ca.key.<br> -x509 - Вместо создания CSR (см. опцию -new) создать самоподписанный сертификат.<br> -days 500 - Срок действия сертификата 500 дней. Размер периода действия можете настроить по своему усмотрению. Не рекомендуется вводить маленькие значения, так как этим сертификатом вы будете подписывать клиентские сертификаты.<br> -out ca.crt Сертификат сохранить в файл ca.crt.<br> -subj /C=US/ST=NC/L=Asheville/O=My\ Own\ Company/OU=IT\ Department/CN=MyOwn\ Root\ Certificate\ Authority/emailAddress=root@root@example.com - Данные сертификата, пары параметр=значение, перечисляются через '/'. Символы в значении параметра могут быть «подсечены» с помощью обратного слэша «\», например «O=My\ Inc». Также можно взять значение аргумента в кавычки, например, -subj «/xx/xx/xx».<br> <br> Описание параметров:<br> <br> С - Двухсимвольный код страны (Country). Необязательный параметр.<br> ST - Название региона/области/края/республики/… (State Name). Необязательный параметр.<br> L - Название города/поселка/… (Locality Name). Необязательный параметр.<br> O - Название организации (Organization Name). Необязательный параметр.<br> OU - Название отдела (Organization Unit). Необязательный параметр.<br> CN - Имя сертификата, при создании серверных сертификатов используется доменное имя сайта, для клиентских сертификатов может быть использовано что угодно (Common Name). Обязательный параметр. Максимальная длина 64 символа.<br> emailAddress - почтовый адрес (E-mail address). Необязательный параметр. Максимальная длина 40 символов.<br> <br> </html> Необязательные параметры могут быть пропущены, например:
/C=US/emailAddress=root@example.com
Теперь, когда мы имеем CA, мы можем создавать сертификаты и ключи для машин, образующих туннель. Вместо 'host_x' рекомендую
указывать осмысленное имя для машины-сервера и клиентов, что бы потом не запутаться самому.
HOST=«host_x»
openssl req -nodes -newkey rsa:2048 -keyout $HOST.key -keyform PEM -out $HOST.req -outform PEM \ -subj /C=US/ST=CA/L=Msk/O=My\ Organization\ Name/OU=Subunit\ of\ My\ Large\ Organization/CN=mydomain.com/emailAddress=root@mydomain.com
Также данные в 'subject' можно получить из конфигурационного файла. Пример:
HOST="host_x" vim ~/myCA/$HOST.cnf
содержимое $HOST.cnf:
[ req ] prompt = no distinguished_name = server_distinguished_name [ server_distinguished_name ] commonName = mydomain.com stateOrProvinceName = CA countryName = US emailAddress = root@mydomain.com organizationName = My Organization Name organizationalUnitName = Subunit of My Large Organization
создаем новый CSR и ключ:
openssl req -nodes -newkey rsa:2048 -keyout $HOST.key -keyform PEM -out $HOST.req -outform PEM -config ~/myCA/$HOST.cnf
openssl ca -in $HOST.req -out $HOST.crt -config ~/myCA/caconfig.cnf
openssl verify -CApath /~/myCA/private -CAfile ~/myCA/cacert.pem -purpose sslclient $HOST.crt
openvpn --genkey --secret ta.key
openssl dhparam -out dh1024.pem 1024
crl-verify /path/to/crl.pem
openssl ca -revoke bad_crt_file -keyfile ca_key -cert ca_crt
или
openssl ca -config caconfig.conf -revoke bad_crt_file
openssl ca -gencrl -keyfile ca_key -cert ca_crt -out crl.pem
или
openssl ca -gencrl -config caconfig.conf -out crl.pem
| Файл | Машина | Назначение | Доступ |
|---|---|---|---|
| ca.crt | Сервер и клиенты | Сертификат корневого СА | Публичный |
| ca.key | Только на сервере | Необходим для подписи других сертификатов | Секретный |
| 1024.pem | Только на сервере | Diffie Hellman параметры | Публичный |
| remote.domain.com.crt | Только на сервере | Сертификат сервера | Публичный |
| remote.domain.com.key | Только на сервере | Ключ сервера | Секретный |
| laptop.domain.com.crt | Только на клиенте | Сертификат клиента | Публичный |
| laptop.domain.com.key | Только на клиенте | Ключ клиента | Секретный |
Когда OpenVPN узлы уверены в подлинности друг друга, DH может быть использован для создания закрытого разделяемого ключа для хэш функции и алгоритма шифрования. Комбинируя DH закрытый ключ с отрытым DH ключом другого OpenVPN узла, возможно создать закрытый разделяемых ключ, который будет известен только этим двум OpenVPN узлам.
Этот ключ будет использоваться алгоритмом симметричного шифрования и хэш функцией, как это будет показано в следующих двух параграфах.
cipher AES-256-CBC
Конфиденциальность данных обеспечивается симметричными алгоритмами шифрования 3DES или AES. По умолчанию используется алгоритм Blowfish. Список доступных алгоритмов можно получить так:
#openvpn --show-ciphers DES-CBC 64 bit default key (fixed) IDEA-CBC 128 bit default key (fixed) RC2-CBC 128 bit default key (variable) DES-EDE-CBC 128 bit default key (fixed) DES-EDE3-CBC 192 bit default key (fixed) DESX-CBC 192 bit default key (fixed) BF-CBC 128 bit default key (variable) RC2-40-CBC 40 bit default key (variable) CAST5-CBC 128 bit default key (variable) RC5-CBC 128 bit default key (variable) RC2-64-CBC 64 bit default key (variable) AES-128-CBC 128 bit default key (fixed) AES-192-CBC 192 bit default key (fixed) AES-256-CBC 256 bit default key (fixed)
'CBC (Cipher Block Chaining)' это режим шифрования используемый блочными алгоритмами шифрования такими как AES, DES или Blowfish. CBC использует маленькие порции данных, вместо обработки всего блока за один раз. Другие доступные режимы шифрования: EBC, OFB, CFB. Рекомендуется использовать CBC.
Целостность данных (защита от их изменения) достигается использованием хэш функций. HMAC часто используется в дополнении с SHA1 или MD5. OpenVPN использует по умолчанию HMAC-SHA1.
Список доступных алгоритмов можно получить так:
#openvpn --show-digests MD2 128 bit digest size MD5 128 bit digest size RSA-MD2 128 bit digest size RSA-MD5 128 bit digest size SHA 160 bit digest size RSA-SHA 160 bit digest size SHA1 160 bit digest size RSA-SHA1 160 bit digest size DSA-SHA 160 bit digest size DSA-SHA1-old 160 bit digest size MDC2 128 bit digest size RSA-MDC2 128 bit digest size DSA-SHA1 160 bit digest size RSA-SHA1-2 160 bit digest size DSA 160 bit digest size RIPEMD160 160 bit digest size RSA-RIPEMD160 160 bit digest size MD4 128 bit digest size RSA-MD4 128 bit digest size
«openvpn –show-tls» отображает алгоритмы шифрование и MAC (Message Authentication Code) используемый SSL/TLS во время установления соединения. Их не нужно путать с шифрованием и MAC используемых для обеспечения безопасности OpenVPN туннеля.