Настройка OCSP Stapling на Apache
Отредактируйте файл виртуальных хостов SSL и внесите в директиву <VirtualHost></VirtualHost> следующий код:
Затем укажите расположение кэша вне директивы <VirtualHost></VirtualHost>.
Если вы следовали данному руководству по установке SSL-сертификатов на Apache, файл виртуального хоста будет выглядеть так:
Затем протестируйте конфигурации, чтобы заранее выявить ошибки:
Если появится сообщение «Syntax OK», перезапустите сервер.
Теперь перейдите на веб-сайт через IE (в Vista и т.п.) или Firefox 26 + и проверьте журнал ошибок.
Если файл, указанный в директиве SSLCACertificateFile, отсутствует, будет выведено подобное сообщение об ошибке:
Если никаких сообщений об ошибках не появилось, переходите к завершающим действиям.
Creating Our Entrypoint Script:
This will be our script that will run at run time and we want to add some environment variables to add the ability to change the certificate and key out.
touch ~/Documents/nginx-alpine-ssl/config/entrypoint.sh
File:
# Main shell script that is run at the time that the Docker image is run# Go to default.conf directorycd /etc/nginx/conf.d;# ENV VARS# A list of environment variables that are passed to the container and their defaults# CRT - double check that the file existsexport CRT="${CRT:=nginx-selfsigned.crt}";if [ -f "/etc/ssl/certs/$CRT" ]then # set crt file in the default.conf file sed -i "/ssl_certificate \//c\\\tssl_certificate \/etc\/ssl\/certs\/$CRT;" default.conf;fi# KEY - double check that the file existsexport KEY="${KEY:=nginx-selfsigned.key}";if [ -f "/etc/ssl/private/$KEY" ]then # set key file in the default.conf file sed -i "/ssl_certificate_key \//c\\\tssl_certificate_key \/etc\/ssl\/private\/$KEY;" default.conf;fi# Needed to make sure nginx is running after the commands are runnginx -g 'daemon off;'; nginx -s reload;
Add Our Certificate To Keychain Access
Drag our newly created to the app.
Running Container With New Keys
Now we have our new and files located in our new folder. With them, we can use them with our new environment variables defined by our file:
# -v is mounting both to the certs and private folder in docker# -e CRT=name of certificate# -e KEY=name of keydocker run -it -d -v $PWD/certkey:/etc/ssl/private/ -v $PWD/certkey:/etc/ssl/certs/ -e CRT=new-selfsigned.crt -e KEY=new-selfsigned.key -p 80:80 -p 443:443 --name newssl nginxssltest;
If we open our browser now to https://newdomain.com, we’ll see:
https://newdomain.com working with the new certificates
Docker Hub Automatic Builds
This next part is to bring it all together with a GitHub repository and a connected Docker Hub repository that creates automatic builds for us to use.
Squid Configuration File
Squid must be built with:
./configure \
--with-openssl \
--enable-ssl-crtd
Paste the configuration file like this:
http_port 3128 ssl-bump \ cert=/etc/squid/ssl_cert/myCA.pem \ generate-host-certificates=on dynamic_cert_mem_cache_size=4MB # For squid 3.5.x sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /var/lib/ssl_db -M 4MB # For squid 4.x # sslcrtd_program /usr/local/squid/libexec/security_file_certgen -s /var/lib/ssl_db -M 4MB acl step1 at_step SslBump1 ssl_bump peek step1 ssl_bump bump all
Alternative trust roots
In some cases you may need to specify custom root CA to be added to the library default «Global Trusted CA» set. This is done by
Squid-3.5 and older:
sslproxy_cafile /usr/local/openssl/cabundle.file
Squid-4 and newer:
tls_outgoing_options cafile=/usr/local/openssl/cabundle.file
Note: OpenSSL CA’s bundle is derived from Mozilla’s bundle and is NOT COMPLETE. Specifically most intermediate certificates are not included (see below). Adding extra root CA in this way is your responsibility. Also beware, when you use OpenSSL, you need to make c_rehash utility before Squid can use the added certificates. Beware — you can’t grab any CA’s you see. Check it before use!
Missing intermediate certificates
Some global root servers use an intermediate certificate to sign, and sometimes servers do not deliver all the intermediate certificates in the chain up to their root CA.
Squid-4 is capable of downloading missing intermediate CA certificates, like popular browsers do.
For Squid-3.5 the sslproxy_foreign_intermediate_certs directive can be used to load intermediate CA certificates from a file:
sslproxy_foreign_intermediate_certs /etc/squid/extra-intermediate-CA.pem
Older versions of Squid cannot handle intermediate CA certificates very well. You may be able to find various hacks for certain situations around, but it is highly recommended to upgrade to at least the latest Squid-3.5 version when dealing with HTTPS / TLS traffic.
Per-User or Per Group Configuration
Ocserv allows per user and per group configurations. To enable this feature, uncomment the following two lines in file.
config-per-user = /etc/ocserv/config-per-user/ config-per-group = /etc/ocserv/config-per-group/
Save and close the file. Then create the per user and per-group config directory.
sudo mkdir /etc/ocserv/config-per-user/ sudo mkdir /etc/ocserv/config-per-group/
Next, you can create a file under these two directories. For example, create the file to allow custom configuration for .
sudo nano /etc/ocserv/config-per-user/user1
You can also create the file to allow custom configuration for the group named .
sudo nano /etc/ocserv/config-per-group/group1
You can add something like below in the file.
route = 10.10.10.0/255.255.255.0
This means that after connect to this VPN server, only traffic to the network will be routed via VPN server. Traffic to other IP addresses are routed via the original gateway. This is known as split tunneling, which is useful when:
- You just want the VPN clients to be able to browse internal resources and don’t want all the traffic to go through the VPN server.
- You need to build a private network for cloud servers.
- The client needs to connect to multiple VPNs. One VPN could use split tunneling and the other use a full tunnel.
Save and close the file. Restart for the changes to take effect.
Wildcard certificates
supports creating wildcard certificates, i.e. *.example.com which allows a single certificate to be used for any domain under example.com, e.g. , mail.example.com. These must be validated using the dns-01 method.
A partial example file is:
VALIDATE_VIA_DNS=true export CPANEL_USERNAME='' export CPANEL_URL='https://www.cpanel.host:2083' export CPANEL_APITOKEN='1ABC2DEF3GHI4JKL5MNO6PQR7STU8VWX9YZA' DNS_ADD_COMMAND=/home/root/getssl/dns_scripts/dns_add_cpanel DNS_DEL_COMMAND=/home/root/getssl/dns_scripts/dns_del_cpanel
Create the wildcard certificate (need to use quotes to prevent globbing):
getssl "*.example.domain"
You can renew the certificate using to renew all configured certificates.
You can also specify additional domains in the line, e.g. .
This cannot contain any of the domains which would be covered by the wildcard certificate.
Настройка сертификатов в браузере
firefox
Сейчас большинство сайтов используют технологию HSTS для предотвращения MiTM атак, поэтому если вы хотите настроить Squid для фильтрации трафика в своей организации, вам следует добавить сертификат squid.der сгенерированный на предыдущем шаге в браузер. Рассмотрим на примере Firefox. Откройте Настройки -> Защита и приватность -> Просмотр сертификатов -> Центры сертификации.
Затем нажмите кнопку Импортировать и выберите файл squid.der. Отметьте галочки, что следует доверять этому сертификату.
Yandex Browser
Откройте Настройки -> Системные -> Управление сертификатами -> Центры сертификации.
Затем нажмите кнопку Импорт и выберите файл squid.der. Отметьте галочки, что следует доверять этому сертификату.
Подключение по SSH
Подключение происходит с помощью команды
ssh + имя_пользователя + хост
Например
Если вы подключаетесь к хосту впервые, появится предупреждение
The authenticity of host ‘192.168.56.101 (192.168.56.101)’ can’t be established.
ECDSA key fingerprint is SHA256:db8az/qbrWOJWvNRv2d9UHaDBnnUHanJ9Svca9vFx7c.
Are you sure you want to continue connecting (yes/no/)?
Если выбрать yes
то в файл
~/.ssh/known_hosts
добавится похожая строка:
|1|abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1= ssh-rsa abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567
Обычно файл
known_hosts
имеет следующий формат (записи идут через пробел)
Таким образом
abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1=
Это хэш от имени сервера.
Здесь через пробел записаны три элемента: хэш от имени сервера, название используемого ассиметричного алгоритма и публичный ключ сервера. Разберём их по очереди.
Как проверить, поддерживает ли HTTPS сервер определённый протокол
По умолчанию s_client будет пытаться использовать лучший протокол для связи с удаленным сервером и сообщать согласованную версию в выходных данных.
Protocol : TLSv1.3
Если вам нужно протестировать поддержку определённых версий протокола, у вас есть два варианта. Вы можете явно выбрать один протокол для тестирования, указав один из ключей —ssl3, -tls1, -tls1_1, -tls1_2 или -tls1_3. Кроме того, вы можете выбрать протоколы, которые вы не хотите тестировать, используя один или несколько из следующих параметров: -no_ssl3, -no_tls1, -no_tls1_1, -no_tls1_2 или -no_tls1_3.
Примечание: не все версии OpenSSL поддерживают все версии протокола. Например, более старые версии OpenSSL не будут поддерживать TLS 1.2 и TLS 1.3, а более новые версии могут не поддерживать более старые протоколы, такие как SSL 2 и SSL 3. К примеру, при попытке использовать опцию -ssl3 на современных версиях OpenSSL возникает ошибка:
s_client: Option unknown option -ssl3
Подмена сертификатов
Сгенерируем свой сертификат… лет так на 10 
proxyCA.pem — и сертификат и ключ в одном файле
Создадим сертификат для установки его на компьютеры пользователей (корневой)
Скопируем squid.der на свой компьютер, это сертификат для установки его на клиентские компьютеры… Установим его либо руками, либо групповой политикой. Как это сделать будет описано далее.
Генерируем файл параметров
Настроим права на использование файла SSL-сертификата и файла параметров
Выставляем права на и /
Создаем каталог для базы данных сертификатов и инициализируем базу данных
Следующим шагом включаем ip_forwarding для разрешения проходящего трафика через сервер:
Применяем конфигурацию
Затем можно перезапускать Squid:
Осталось настроить редирект и браузер.
Сгенерировать пару ключей
Первый шаг — это генерация пары ключей. Обычно это делается на клиентской машине.
Например, на вашем ноутбуке.
Основная команда ssh-keygen создаст 2048-битную пару RSA ключей. Для
большей надёжности можно добавить флаг -b 4096
Выполните
ssh-keygen -b 4096
Чтобы сгенерировать ключ в /home/$(whoami)/.ssh
или
sudo ssh-keygen -b 4096
Чтобы сгенерировать ключ в /home/root/.ssh
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Нужно придумать имя ключа.
Я назову ключ
andrei-key101
а сохранять буду в текущую директорию.
Enter file in which to save the key (/root/.ssh/id_rsa): andrei-key101
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Нужно два раза ввести пароль. Если он вам нужен. Обычно нет.
Your identification has been saved in andrei-key101
Your public key has been saved in andrei-key101.pub
The key fingerprint is:
SHA256:abcd/abcdefghijklmnopqrstuvwxyz1234567890ab root@urn-su
The key’s randomart image is:
+——-+
|=o oo++ |
|= oo o. = o |
|+ |
|Oo=o . . |
|B+.o S . |
|+o.o |
|+.0. . |
|o+= . E |
|+=oo. . . |
+———+
Ключи готовы. Я сохранил их в текущую директорию поэтому увижу их сделав ls
ls
andrei-key101 andrei-key101.pub
Важно помнить, что если вы генерируете ключ для другого пользователя нужно
позаботиться о правильных правах доступа к этому ключу.
Outline
This configuration is written for Squid-3.5. It will definitely not work on older Squid releases even though they have a form of the SSL-Bump feature, and may not work on newer versions if there have been any significant improvements to the TLS protocol environment.
TLS is a security protocol explicitly intended to make secure communication possible and prevent undetected third-party (such as Squid) interception of the traffic.
when used properly TLS cannot be «bumped».
Even incorrectly used TLS usually makes it possible for at least one end of the communication channel to detect the proxies existence. Squid SSL-Bump is intentionally implemented in a way that allows that detection without breaking the TLS. Your clients will be capable of identifying the proxy exists. If you are looking for a way to do it in complete secrecy, dont use Squid.
Install and Use OpenConnect VPN client on CentOS 8/Fedora Desktop
Run the following command to install OpenConnect VPN command-line client on Fedora desktop.
sudo dnf install openconnect
On CentOS 8, you need to enable the EPEL repository in order to install the client.
sudo dnf install epel-release sudo dnf install openconnect
Then you can connect to VPN server from the command line like below. flag will make it run in the background after the connection is established.
sudo openconnect -b vpn.example.com
By default, openconnect client sends request to port 443 of the server. If you configured a different port for the server, then you can add the port number.
sudo openconnect -b vpn.example.com:port-number
You will be asked to enter VPN username and password. If connection is successfully established, you will see the following message.
Got CONNECT response: HTTP/1.1 200 CONNECTED CSTP connected. DPD 90, Keepalive 32400 Connected as 10.10.10.139, using SSL + lz4 Continuing in background; pid 2137 Established DTLS connection (using GnuTLS). Ciphersuite (DTLS1.2)-(PSK)-(AES-256-GCM).
If the connection failed, you can check the ocserv log to find out why. (Perhaps you didn’t enter the password correctly.)
sudo journaltcl -eu ocserv
To stop the connection, run:
sudo pkill openconnect
To run the client non-interactively, use the following syntax.
echo -n password | sudo openconnect -b vpn.example.com -u username --passwd-on-stdin
If you are successfully connected to the VPN server, but your public IP address doesn’t change, that’s because IP forwarding or IP masquerading is not working.
ssh-copy-id
Я предпочитаю использовать с флагом -i и задавать путь до нужного ключа
sudo ssh-copy-id -i ~/.ssh/andrei-key.pub [email protected]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: «/home/andrei/.ssh/andrei-key.pub»
The authenticity of host ‘192.168.0.2 (192.168.0.2)’ can’t be established.
ECDSA key fingerprint is SHA256:abcdefgh1234567890abcdefgh1234567890abc+def.
Are you sure you want to continue connecting (yes/no/)?
Введите yes
Are you sure you want to continue connecting (yes/no/)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys
[email protected]’s password:
Введите пароль
Number of key(s) added: 1
Now try logging into the machine, with: «ssh ‘[email protected]′»
and check to make sure that only the key(s) you wanted were added.
Теперь на хосте 192.168.0.2 в файле
/home/andrei/.ssh/authorized_keys
появилась новая запись вида
ssh-rsa AAAAB3NzaC1y … lseP/jXcq … Uydr/2CwQ &hellip ++TpY19pHqD/AnhL … Az62T/Ipyx … 8U2T [email protected]
Знак … заменяет длинные последовательности случайных символов для экономии места.
Проверить ключ можно командой
ssh -i ~/.ssh/mykey user@host
В нашем случае
ssh -i ~/.ssh/andrei-key [email protected]
Если вы не задавали пароль для ключа, то попадёте на удалённый хост без лишних движений
Last login: Sun Jan 10 16:48:27 2021 from 192.168.0.1
Как пользоваться s_client
Команда s_client выполняет функции SSL/TLS клиента для подключения к удалённому хосту с использованием SSL/TLS. Данная программа позволяет подключаться с различными настройками SSL/TLS — выбирать используемые шифры, версию рукопожатия, использовать определённые протоколы, тестировать повторное использование сессий. При этом программа показывает все переданные и полученные во время SSL/TLS подключения данные. Благодаря этому возможна доскональная проверка настроек сервера SSL/TLS, тестирование списка отзыва сертификатов и даже проверка на уязвимости.
Выполнив SSL/TLS подключение, s_client позволяет вводить данные, например, отправлять заголовки HTTP протокола, команды SMTP, FTP и т.д.
Для подключения к удалённому хосту укажите адрес домена и порт (обычно это 443) с опцией -connect:
openssl s_client -connect yandex.ru:443
Вы увидите:
1. верификацию и цепочку сертификатов
2. сертификат сайта
3. данные текущей сессии — SSL/TLS (ассиметричное шифрование) используются для обмена ключом для симметричного шифрования, поскольку ассиметричное слишком «затратное». И фактический шифрование данных будет выполняться «паролем» (ключами сессии, а не сертификатом). Эти ключи меняются при каждой новой сессии.
То есть, компрометация приватного ключа сервера ≠ расшифровка трафика. Поскольку необходимо знать все ключи сессии. Раньше, зная приватный ключ сервера, можно было расшифровать SSL трафик — сначала расшифровывались ключи сессии, а затем они использовались для расшифровки данных. Но теперь используется Perfect Forward Secrecy (которая применяет Diffie-Hellman key exchange (DH)), что привело к тому, что третья сторона, даже зная приватный ключ RSA (приватный ключ сервера), не сможет расшифровать TLS трафик.
Speed Optimization
OpenConnect by default uses TLS over UDP protocol (DTLS) to achieve faster speed, but UDP can’t provide reliable transmission. TCP is slower than UDP but can provide reliable transmission. One optimization tip I can give you is to disable DTLS, use standard TLS (over TCP), then enable TCP BBR to boost TCP speed.
You may also want to disable DTLS to bypass firewall restrictions because DTLS uses UDP port 443. Standard TLS uses TCP port 443.
To disable DTLS, comment out (add # symbol at the beginning) the following line in ocserv configuration file.
udp-port = 443
Save and close the file. Then restart ocserv service.
sudo systemctl restart ocserv.service
To enable TCP BBR, please check out the following tutorial. It’s written for Ubuntu, but also works for CentOS. Note that you need to disable DTLS in ocserv, or TCP BBR won’t work.
How to Easily boost Server Network Performance by enabling TCP BBR
In my test, standard TLS with TCP BBR enabled is two times faster than DTLS.
Another very important factor affecting speed is how good the connection between your local computer and the VPN server is. If you live in the middle east and the VPN server is located in the U.S, the speed would be slow. Choose a data center that’s close to where you live.
Generate New Certificate & Key
Next, we’ll generate new and files in a new folder called . To do this though, Mac OS doesn’t support and instead of going the route of trying to reconfiguring our local file, we’ll just use an alpine docker image as a one time use to generate the keys we need.
mkdir ~/Documents/nginx-alpine-ssl/certkey;cd ~/Documents/nginx-alpine-ssl;# --rm will remove the container after it's rundocker run --rm -v $PWD/certkey:/usr/share alpine /bin/sh -c "apk add openssl; openssl req -x509 -nodes -days 365 -subj \"/C=CA/ST=QC/O=Company, Inc./CN=newdomain.com\" -addext \"subjectAltName=DNS:newdomain.com\" -newkey rsa:2048 -keyout /usr/share/new-selfsigned.key -out /usr/share/new-selfsigned.crt;"
Create and initialize TLS certificates cache directory
Finally you need to create and initialize TLS certificates cache directory and set permissions to allow access by Squid.
The crtd helper will store mimicked certificates in this directory. The squid low-privilege account needs permission to both read and write there.
Squid-3.5:
/usr/local/squid/libexec/ssl_crtd -c -s /var/lib/ssl_db -M 4MB chown squid:squid -R /var/lib/ssl_db
Squid-4 and newer:
/usr/local/squid/libexec/security_file_certgen -c -s /var/lib/ssl_db -M 4MB chown squid:squid -R /var/lib/ssl_db
-
The low-privilege account varies by OS and may not be ‘squid’ in your system.
-
also, be aware that SELinux and AppArmour permissions may need to be updated to allow the Squid helper to use this directory.
-
certificates cache directory used only if squid configured with —enable-ssl-crtd. Otherwise bump will work, but no certificates will store anywhere.
Автоматическое продление SSL-сертификата Let’s Encrypt
Сертификаты Let’s Encrypt действительны в течение 90 дней. Чтобы автоматически продлевать сертификаты до истечения срока их действия, пакет certbot создает задание cron, которое запускается дважды в день и автоматически обновляет любой сертификат за 30 дней до истечения срока его действия.
После обновления сертификата нам также необходимо перезагрузить службу Apache. Добавьте в файл чтобы он выглядел следующим образом:
/etc/cron.d/certbot
Чтобы протестировать процесс обновления, вы можете использовать переключатель :
Если ошибок нет, значит процесс продления прошел успешно.
Create
Create a self-signed certificate with OpenSSL
The commands below and the configuration file create a self-signed certificate (it also shows you how to create a signing request).
Note: The Common Name (CN) is deprecated — the hostname will be matched against available names in the Subject Alternate Name (SAN) field. So enter the main hostname as CN and list it together with the rest of your DNS records in the SAN field.
The DNS names are placed in the SAN through the configuration file with the line (there’s no way to do it through the command line). Then there’s an section in the configuration file (you should tune this to suit your taste):
It’s important to put DNS name in the SAN and not the CN, because both the IETF and the CA/Browser Forums specify the practice. They also specify that DNS names in the CN are deprecated (but not prohibited). If you put a DNS name in the CN, then it must be included in the SAN under the CA/B policies. So you can’t avoid using the Subject Alternate Name.
If you don’t do put DNS names in the SAN, then the certificate will fail to validate under a browser and other user agents which follow the CA/Browser Forum guidelines.
Related: browsers follow the CA/Browser Forum policies; and not the IETF policies. That’s one of the reasons a certificate created with OpenSSL (which generally follows the IETF) sometimes does not validate under a browser (browsers follow the CA/B). They are different standards, they have different issuing policies and different validation requirements.
View
Even though PEM encoded certificates are ASCII they are not human readable. Here are some commands that will let you output the contents of a certificate in human readable form.
View PEM encoded certificate
Use the command that has the extension of your certificate replacing cert.xxx with the name of your certificate
If you get the following error it means that you are trying to view a DER encoded certifciate and need to use the commands in the “View DER encoded certificate” section below:
View DER encoded certificate
If you get the following error it means that you are trying to view a PEM encoded certificate with a command meant for DER encoded certs. Use a command in the “View PEM encoded certificate” section above:
Как добавить корневой сертификат в доверенные в Linux на уровне системы
Сертификат с расширением .crt можно открыть двойным кликом и просмотреть его содержимое:
Если вы работаете в системе от обычного пользователя (не root), то кнопка «Импортировать» будет недоступна.
Чтобы разблокировать кнопку «Импортировать», выполните следующую команду:
sudo gcr-viewer /ПУТЬ/ДО/СЕРТИФИКАТА.crt
Например:
sudo gcr-viewer ./HackWareCA.crt
Данный способ может не сработать, поэтому рассмотрим, как добавить доверенные корневые центры сертификации в командной строке.
Суть метода очень проста:
- Добавить свой корневой CA сертификат в папку, предназначенную для таких сертификатов.
- Запустить программу для обновления общесистемного списка сертификатов.
Пути и команды в разных дистрибутивах Linux чуть различаются.
Просмотреть Subject всех корневых CA сертификатов можно уже знакомой командой:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt
Для демонстрации я добавлю сертификат с Common Name, включающим «HackWare», тогда для проверки, имеется ли сертификат с таким именем среди корневых CA, я могу использовать команду:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare
Для добавления своего корневого CA в доверенные в Debian, Kali Linux, Linux Mint, Ubuntu и их производных:
1. Проверьте, существует ли директория /usr/local/share/ca-certificates:
ls -l /usr/local/share/ca-certificates
Если её ещё нет, то создайте:
sudo mkdir /usr/local/share/ca-certificates
Сертификат должен быть в формате PEM (обычно так и есть) и иметь расширение .crt — если расширение вашего сертификата .pem, то достаточно просто поменять на .crt.
2. Скопируйте ваш сертификат командой вида:
sudo cp СЕРТИФИКАТ.crt /usr/local/share/ca-certificates/
Например:
sudo cp ./HackWareCA.crt /usr/local/share/ca-certificates/
3. Запустите следующую команду для обновления общесистемного списка:
sudo update-ca-certificates
Пример вывода:
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Adding debian:HackWareCA.pem done. done.
Проверим наличие нашего CA сертификата среди доверенных:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare
Сертификат успешно найден:
Чтобы его удалить:
sudo rm /usr/local/share/ca-certificates/СЕРТИФИКАТ.crt sudo update-ca-certificates
Для добавления своего корневого CA в доверенные в Arch Linux, BlackArch и их производных:
1. Выполните команду вида:
sudo cp ./СЕРТИФИКАТ.crt /etc/ca-certificates/trust-source/anchors/
Например:
sudo cp ./HackWareCA.crt /etc/ca-certificates/trust-source/anchors/
2. Обновите общесистемный список доверенных CA:
sudo update-ca-trust
Чтобы удалить этот сертификат:
sudo rm /etc/ca-certificates/trust-source/anchors/СЕРТИФИКАТ.crt sudo update-ca-trust
API
This is just a convenience method so that you don’t
have to require and if you don’t need them.
require('ssl-root-cas/latest').addFile(__dirname+'/ssl/03-cheap-ssl-site.pem');
is the same as
var https =require('https');var cas;cas =https.globalAgent.options.ca||;cas.push(fs.readFileSync(path.join(__dirname,'ssl','03-cheap-ssl-site.pem')));https.globalAgent.options.ca= cas;
If for some reason you just want to look at the array of Root CAs without actually injecting
them, or you just prefer to
yourself, well, you can.
(deprecated)
I thought it might be rude to modify on ,
so I afford you the opportunity to the certs at your leisure.
keeps track of whether or not it’s been run, so no worries about calling it twice.
'use strict';var request =require('@coolaj86/urequest');var agentOptions;var agent; agentOptions ={ host'www.example.com', port'443', path'', rejectUnauthorizedfalse}; agent =newhttps.Agent(agentOptions);request({ url"https://www.example.com/api/endpoint", method'GET', agent agent},function(err,resp,body){});
By using an with you at limit the security vulnerability to the requests that deal with that one site instead of making your entire node process completely, utterly insecure.
If you were using a self-signed cert you would add this option:
agentOptions.ca= selfSignedRootCaPemCrtBuffer ;
For trusted-peer connections you would also add these 2 options:
agentOptions.key= clientPemKeyBuffer;agentOptions.cert= clientPemCrtSignedBySelfSignedRootCaBuffer;
Don’t use dissolutions such as these.
This will turn off SSL validation checking. This is not a good idea. Please do not do it.
(really I’m only providing it as a reference for search engine seo so that people who are trying
to figure out how to avoid doing that will end up here)
process.env.NODE_TLS_REJECT_UNAUTHORIZED=""
The same dissolution from the terminal would be
export NODE_TLS_REJECT_UNAUTHORIZED=""node my-service.js
It’s unfortunate that is even documented. It should only be used for debugging and should never make it into in sort of code that runs in the wild. Almost every library that runs atop has a way of passing agent options through. Those that don’t should be fixed.
Other information you might want to know while you’re here.
Настройка OCSP stapling на Nginx
Отредактируйте файл виртуального хоста и внесите в раздел server {} следующий блок кода:
Если, чтобы настроить SSL-сертификаты на Nginx, вы следовали данной статье, то виртуальный хост будет выглядеть так:
Теперь нужно убедиться, что все работает должным образом; для этого нужно протестировать конфигурации:
Перезапустите nginx:
Затем откройте веб-сайт через IE (в Vista и т.п.) или Firefox 26 + и проверьте журнал ошибок.
Если в файле, указанном в ssl_trusted_certificate, отсутствует сертификат, появится ошибка:
Если же ошибок не обнаружено, переходите к следующему разделу руководства.
Running Our Container
Let’s run our container and then do a test:
docker run -it -d -p 80:80 -p 443:443 --name test nginxssltest;curl localhost;# Expected output# <h1>Hello world!</h1>curl https://localhost --insecure;# Expected output# <h1>Hello world!</h1>
If we open up our browser, with our certificate trusted by our computer, we can see it works:
https://mydomain.com Working
Testing Different Keys
Now that we see that it’s working, let’s test another domain with different generated keys.
First, let us modify out file to add a new domain to it.
sudo nano /etc/hosts;
File:
### Host Database## localhost is used to configure the loopback interface# when the system is booting. Do not change this entry.##127.0.0.1 localhost255.255.255.255 broadcasthost::1 localhost127.0.0.1 mydomain.com127.0.0.1 newdomain.com
/etc/hosts
Virtual Hosting
To add a new virtual host in ocserv, first you need to use the method in step 4 to obtain a TLS certificate for the new virtual host. Then edit ocserv configuration file.
sudo nano /etc/ocserv/ocserv.conf
Go to the bottom of this file. In Nano text editor, you can press , then to jump to the bottom of a file. Add the following lines. Replace with the hostname of the second virtual host.
#Allow password authentication and certificate authentication enable-auth = "plain[passwd=/etc/ocserv/ocpasswd]" auth = "certificate" tcp-port = 443 #uncomment the two lines if ocserv runs behind HAProxy. #listen-host = 127.0.0.1 #listen-proxy-proto = true # SSL/TLS configuration ca-cert = /etc/ocserv/ssl/ca-cert.pem server-cert = /etc/letsencrypt/live/vpn2.example.com/fullchain.pem server-key = /etc/letsencrypt/live/vpn2.example.com/privkey.pem cert-user-oid = 0.9.2342.19200300.100.1.1 #Networking configuration. Use a different network range for this virtual host. device = vpns ipv4-network = 10.10.20.0 ipv4-netmask = 255.255.255.0 route = default dns = 8.8.8.8 tunnel-all-dns = true compression = true max-clients = 0 max-same-clients = 0 try-mtu-discovery = true idle-timeout=1200 mobile-idle-timeout=2400 config-per-user = /etc/ocserv/config-per-user/ config-per-group = /etc/ocserv/config-per-group/
Save and close the file. Then restart ocserv.
sudo systemctl restart ocserv
Note that the ocserv daemon might tell you some parameters will be ignored for virtual host. However, I found that some of the ignored parameters are actually needed. For example, if you delete the line from the virtual host, you might encounter the following error when establishing VPN connection to the virtual host.
VPN service unavailable; reason: Server configuration error
And the VPN server would produce the following error message in the log.
no networks are configured; rejecting client
Note that the AnyConnect VPN client on iOS doesn’t support TLS SNI, so iOS users will connect to the default virtual host.
