Tls auth: Дополнительные возможности OpenVPN по обеспечению безопасности частной сети

Дополнительные возможности OpenVPN по обеспечению безопасности частной сети

Если вы используете OpenVPN для создания виртуальных частных сетей в своей инфраструктуре, рекомендуем обратить внимание на дополнительные инструменты обеспечения безопасности, предлагаемые для этого продукта. Ниже приведен список основных доступных для использования опций. 

Частное облако от 1cloud.ru

• Любые конфигурации виртуальных серверов
• Бесплатные частные сети
• Полная автоматизация управления

Примечание: данный материал подразумевает наличие у вас готовой к работе базовой конфигурации OpenVPN. Если такая конфигурация еще не развернута, вы можете воспользоваться одной из наших подробных инструкций по настройке OpenVPN-сервера:

tls-auth

Параметр tls-auth добавляет использование еще одной подписи HMAC к handshake-пакетам SSL/TLS, инициируя дополнительную проверку целостности. Теперь пакет, не имеющий такой подписи, будет отбрасываться, не обрабатываясь. Это обеспечит дополнительный уровень безопасности протокола SSL/TLS, защищая систему от таких атак, как:

• Сканирование прослушиваемых VPN-сервером портов
• Инициация SSL/TLS-соединения несанкционированной машиной (хотя подобные рукопожатия не проходят и при стандартной конфигурации OpenVPN, tls-auth отсекает их на значительно более раннем этапе)
• DoS-атаки и флуд на порты OpenVPN
• Переполенение буфера SSL/TLS

Для активации tls-auth необходимо сгенерировать дополнительный секретный ключ, который будет использоваться совместно со стандартной парой ключей RSA.Сделать это можно с помощью следующей команды:

openvpn --genkey --secret ta.key

Теперь в стандартной директории, в которой хранятся сгенерированные ключи (easy-rsa) появится еще один файл ta.key, который нужно перенести на все устройства сети OpenVPN через защищенный канал (в те же директории, в которых хранятся пользовательские ключи .crt и .key. Затем следует добавить или расскоментировать в файле конфигурации сервера (server.conf) следующую строку:

tls-auth ta.key 0

Также нужно в файле настроек клиента (client.ovpn) добавить/расскоментировать аналогичную строку:

tls-auth ta.key 1

proto udp

Несмотря на то, что OpenVPN предусматривает использование как TCP, так и UDP-протокола для подключения, рекомендуем использовать UDP, так как он обеспечивает более высокий уровень защиты от DoS-атак и сканирования портов сравнительно с протоколом TCP. Выбор протокола устанавливается опцией proto в файле конфигурации сервера. Установите proto udp.

Внимание! Если вы сменили протокол на уже работающем сервере, не забудьте сделать это также в файлах конфигурации клиентов, а затем проверить разрешение для используемого порта UDP (по-умолчанию 1194) в вашем Firewall и перезапустить VPN-сервер.

user/group (не работает на Windows)

Сброс привилегий суперпользователя сразу после активации VPN — хороший способ сделать сервер менее привлекательной целью для различных атак. Рекомендуем всегда использовать эту опцию на серверах под управлением Linux/BSD. Этот параметр устанавливается в следующих строках файлов конфигурации сервера/клиента:

user nobody

group nobody

Работа VPN в непривилегированном режиме (только для Linux)

OpenVPN может работать вовсе без привелегий на машинах под управлением Linux. Такая конфигурация является более сложной в развертывании, но обеспечивает повышенный уровень безопасности. Для ее реализации нужно настроить OpenVPN на использование интерфейса iproute. Для этого укажите —enable-iproute2 в параметрах скрипта configure. Для настройки вам также понадобится установленный на машине пакет sudo.

Такая конфигурация основана на возможности Linux-систем устанавливать разрешения на создаваемый демоном OpenVPN виртуальный сетевой адаптер tun так, чтобы непривилегированный пользователь мог получить доступ к нему. Для изменения параметров сетевого интерфейса и таблицы маршрутизации обычным (не «super») пользователем при запуске iproute следует использовать параметр sudo.

Настройка OpenVPN на работу в непривилегированном режиме:

Добавьте представленный ниже скрипт в файл /usr/local/sbin/unpriv-ip (не забудьте указать этому файлу права на исполнение):

#!/bin/sh

sudo /sbin/ip $*

Чтобы разрешить для пользователя (в нашем примере ‘1cloud’) выполнение /sbin/ip откройте visudo и добавьте следующую строку:

1cloud ALL=(ALL) NOPASSWD: /sbin/ip

Вы можете дать разрешения также и для группы пользователей:

%users ALL=(ALL) NOPASSWD: /sbin/ip

Теперь необходимо добавить в файл конфигурации OpenVPN следующие строки:

dev tunX/tapX

iproute /usr/local/sbin/unpriv-ip

(Необходимо выбрать один из интерфейсов (tun или tap) и заменить X на номер вашего интерефейса.

От имени пользователя root активируйте сетевой адаптер и дайте разрешение на управление им для пользователя и/или группы. Команда, приведенная ниже, создаст интерфейс tunX (необходимо заменить на название вашего адаптера) и даст требуемые разрешения для пользователя 1cloud и группы users.

openvpn --mktun --dev tunX --type tun --user 1cloud --group users

Теперь вы можете запустить OpenVPN от имени указанного выше рядового пользователя.

chroot (не работает на Windows)

Параметр chroot обеспечивает блокировку сервиса OpenVPN в условно обозначаемой «тюрьме» (chroot jail), из которой приложение не сможет иметь доступ к какой-либо части файловой системы, кроме определенной директории, указанной в опциях для параметра chroot (для получения подробной информации изучите man 1 chroot и man 2 chroot).

Например, параметр:

chroot jail

Будет означать, что OpenVPN-демон при инициализации попадет в директорию jail и переориентируется на эту папку так, чтобы в дальнейшем для службы OpenVPN не было возможности получить доступ к каким-либо файлам, кроме каталога jail и его подкаталогов. Это имеет существенное значение с точки зрения безопасности, поскольку если злоумышленнику и удастся скомпрометировать VPN-сервер инъекцией кода, «пойманный» эксплойт останется заблокированным в каталоге, полностью изолированном от основной части файловой системы.

Внимание: т.к. опция chroot изменяет домашнюю директорию для сервиса OpenVPN, следует перенести в jail-каталог все используемые при инициализации OpenVPN файлы.

Увеличение размера RSA-ключа

Размер RSA-ключа шифрования устанавливается директивой KEY_SIZE файла easy-rsa/vars, значение которой должно быть установлено до создания любых ключей OpenVPN. По-умолчанию этот параметр имеет значение 1024 bit , но может быть увеличен до 2048 bit без заметного влияния на производительность виртуальной частной сети, за исключением едва заметного увеличения времени рукопожатия (handshake).

Увеличение размера симметричных ключей

При стандартной конфигурации OpenVPN использует Blowfish — 128-битный симметричный ключ шифрования, но при этом может принимать все виды ключей, поддерживаемых библиотекой OpenSSL. Например, вы можете использовать 256-битный шифр AES (Advanced Encryption Standard), добавив в файлы настроек сервера и клиентов OpenVPN параметр:

cipher AES-256-CBC

Хранение закрытого ключа CA на отдельной машине

Перенос файла секретного ключа Центра Сертификации (ca.key) на отдельный компьютер, не подключенный к сети интернет, или на другое безопасное внешнее хранилище — хороший  способ исключить компрометацию существующих и генерацию новых, но не санкционированных ключей X509.

Дело в том, что корневой CA-сертификат не обязательно должен находиться на сервере OpenVPN. Вы вполне можете использовать отдельную машину для подписи ключей, держа ее физически изолированной, и перенося ключи с использованием отличных от интернет каналов, например съемных дисков. Это существенно осложнит потенциальному злоумышленнику задачу кражи ключа Центра Сертификации.

Отзыв сертификатов

Процедура отзыва сертификата подразумевает досрочное прекращение активности ранее созданного и заверенного сертификата пользователя во избежание его дальнейшего использования . Ниже представлены самые распространенные предпосылки для отзыва:

• Закрытый клиентский ключ (.key), связанный с отзываемым сертификатом (.crt), скомпрометирован или украден
• Пользователь забыл пароль пароль для своего ключа
• Вы хотите по собственной инициативе прекратить доступ пользователя к виртуальной частной сети

В рамках данного примера, мы отзовем сертификат пользователя client1.

Войдите в терминал (Linux) или командную строку (Windows) и откройте директорию easy-rsa, аналогично тому, как вы делали это при первичной генерации ключей сервера и клиентов OpenVPN. Введите следующие команды:

Linux:

./vars

./revoke-full client1

Windows:

vars

revoke-full client1

Вы должны увидеть результат, похожий на этот:

Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf DEBUG[load_index]: unique_subject = "yes" Revoking Certificate

04. Data Base Updated Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf

DEBUG[load_index]: unique_subject = "yes"

client2.crt: /C=KG/ST=NA/O=OpenVPN-TEST/CN=client2/[email protected]

error 23 at 0 depth lookup:certificate revoked

Пусть вас не смущает «error 23» в последней строке, т.к. именно этот ответ означает, что отозванный сертификат больше не проходит проверку действительности. Выполнение revoke-full генерирует CRL-файл (certificate revocation list) под именем crl.pem в подкаталоге keys. Этот файл необходимо перенести в рабочую директорию OpenVPN-сервера. Проверка CRL должна быть активирована в файле конфигурации сервера добавлением/расскоментированием строки: crl-verify crl.pem.

Валидация серверного сертификата

Для исключения атак типа Man-in-the-Middle, когда машина злоумышленника выдает себя за VPN-сервер для клиента, следует указать пользователям на необходимость проверки серверного сертификата. Для этого существует несколько способов. В данном примере мы рассмотрим метод, применимый для OpenVPN версий 2.1 и выше:

При генерации сертификата сервера укажите значения полей key usage и extended key usage (см. документацию easy-rsa для получения более подробных сведений). Затем добавьте/расскоментируйте следующую строку в файле параметров клиента:
remote-cert-tls server

Используйте перечисленные выше инструменты для повышения уровня безопасности вашей виртуальной частной сети и обращайте внимание на сохранность других элементов: используемых каналов передачи ключей и сертификатов, физическая сохранность узлов сети VPN, настройки Firewall и антивирусного ПО, права доступа пользователей к рабочим директориям. Надеемся, этот материал поможет вам в достижении ваших задач.

P. S. Другие инструкции:

Спасибо за Вашу оценку!
К сожалению, проголосовать не получилось. Попробуйте позже

OpenVPN c расширенной аутентификацией и авторизацией / Хабр

UPD 2020-07-03: Прошло несколько лет, ситуация сильно изменилась, и в первую очередь я бы сейчас смотрел на wireguard + yubikey. Но все это по-прежнему работает.

В статье рассматривается настройка OpenVPN c дополнительными фичами:

• сертификаты на токенах для первичной аутентификации (на примере Rutoken)
• LDAP-бекенд для вторичной аутентификации (на примере ActiveDirectory)
• фильтрация внутренних ресурсов, доступных для пользователяx (через iptables)

Так же описана настройка клиентов под Linux, Windows и MacOS.

Настройка сервера

Установка OpenVPN

Взять скрипт Nyr/openvpn-install, запустить от root. Этот скрипт я перебрал до строчки, не вижу смысла им не пользоваться.

git clone https://github.com/Nyr/openvpn-install.git
cd openvpn-install

В процесс запуска будет задано несколько вопросов.

• протокол udp
• порт 1194
• DNS-сервера — локальные
• external ip — адрес шлюза в интернете, через который будет доступен vpn-сервер

Так же существует улучшенная в плане безопасности версия исходного скрипта — github.com/Angristan/OpenVPN-install. В ней больше настроек шифрования с пояснениями почему так.

Управление пользователями

Добавление
В случае, если не используются токены, добавление пользователя осуществляется через тот же скрипт. Скрипт по сути генерит пользовательский ovpn-конфиг и вставляет туда сертификат, подписанный корневым сертификатом.

Если используются токены (см. ниже раздел про токены) тогда сертификат выписывается руками на основе запроса на сертификат, который генерится на токене. Пользовательский конфиг надо делать руками из имеющегося шаблона (из того же самого, из которого генерит конфиг скрипт). Шаблон лежит тут /etc/openvpn/client-common.txt. Он не входит в поставку openvpn и генерится скриптом в процессе настройки.

Удаление

Удаление пользователей производится через тот же скрипт установки. Сертификат добавляется в CRL, новый CRL подпихивается vpn-серверу. Все сертификаты, которые есть в CRL сервер считает недействительными и принимать отказывается.

Как отозвать сертификат вручную:

cd /etc/openvpn/easyrsa

# отозвать сертификат
./easyrsa revoke $CLIENT
# сгенерировть новый crl
./easyrsa gen-crl

# удалить старый crl
rm -rf /etc/openvpn/crl.pem
# подменить его новым
cp /etc/openvpn/easy-rsa/pki/crl.pem /etc/openvpn/crl.pem
# openvpn должен уметь читать crl, когда он уже дропнул привилегии до nobody
chown nobody:nobody /etc/openvpn/crl.pem

Фильтрация доступных хостов для клиентов

Клиентов необходимо ограничивать по тем хостам на которые им можно ходить внутри сети, когда они подключаются к openvpn.

Вручную

Идея в том, чтобы ловить пакеты еще на интерфейсе tun0, в который они приходят от клиентов и фильтровать их до того как они попадают в NAT. После NAT фильтровать их будет уже не почему — у них у всех будет ip-адрес openvpn сервера во внутренней сети. До того как попасть в NAT, пакеты у каждого пользователя имеют свой уникальный ip-адрес (соответствие ip-адресов и пользователей можно посмотреть в файле /etc/openvpn/ipp.txt).

Пакеты, которые проходят сквозь систему (не исходят непосредственно из нее и не являются входящими, т.е. по сути роутятся системой) обрабатываются таблицей FORWARD. Таблицы в iptables обрабатываются сверху вниз, если ни одно из правил в таблице не привело к решению судьбы пакета, тогда срабатывает дефолтное правило.

Подготовка таблицы FORWARD:

# сбросить все
iptables -F FORWARD
# дефолтное правило для таблицы FORWARD - не пропускать ничего
iptables -P FORWARD DROP
# пропускать уже установленные соединения
iptables -I FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Пример правил для конкретного клиента. Поскольку дефолтное правило для таблицы — DROP, осталось только разрешить те пары хост+порт, куда можно. Разрешить доступ к порту на хосте + пинговать сам хост:

iptables -I FORWARD -s 10.8.0.3 -i tun0 -d 10.0.2.3  -p tcp --dport 443 -j ACCEPT
iptables -I FORWARD -s 10.8.0.3 -i tun0 -d 10.0.2.3 -p icmp --icmp-type echo-request -j ACCEPT

В примере выше хосту 10.8.0.3 разрешается доступ к порту 443 хоста 10.0.2.3.

Как доступ закрыть:

# показать правила в таблице с указанием их номеров
iptables -L FORWARD --line-numbers
# удаление правила по номеру
iptables -D FORWARD {номер правила}

Потом надо найти все правила для конкретного клиента и удалить их.

Во время отладки удобно смотреть на то, какие правила срабатывают. У каждого правила есть счетчик обработанных пакетов.

# показывать счетчики, с обновлением каждые две секунды
watch iptables -nvL FORWARD
# сбросить счетчики в нули
iptables -Z FORWARD

Автоматически

У openvpn-сервера есть возможность выполнять скрипты при определенных действиях. В частности при подключении и отключении клиентов. Скрипты могут быть написаны на чем угодно, лишь бы были исполняемыми. Внутрь скрипта переменными окружения передаются всякие параметры текущего подключения. Нас интересуют переменные:

• common_name (имя владельца сертификата; то что вбивается в поле common name при создании сертификата)
• ifconfig_pool_remote_ip (ip-адрес клиента на tun0)
• script_type (какое именно событие произошло — подключение или отключение).

Чтобы управлять iptables необходимы привилегии root. Openvpn после подключения сбрасывает права до nobody и от него же выполняет скрипты. Плохо позволять nobody что-то делать из-под sudo, да и звездочкой в правилах лучше не пользоваться, но как-то нужно разрешить пользователю управлять iptables.

# /etc/sudoers.d/50_openvpn
#
# разрешить добавлять правила
nobody ALL = NOPASSWD: /sbin/iptables -A FORWARD*
# разрешить просматривать список правил
nobody ALL = NOPASSWD: /sbin/iptables -L FORWARD*
# разрешить удалять правила
nobody ALL = NOPASSWD: /sbin/iptables -D FORWARD*

В конфиг сервера нужно добавить разрешение выполнять сторонние файлы и включить два хука, отвечающие за подключение и отключение пользователя.

script-security 2
client-connect    /etc/openvpn/bin/hosts.rb
client-disconnect /etc/openvpn/bin/hosts.rb

Сам скрипт, который читает конфиги и применяет правила для iptables. Скрипт работает по тем же принципам, которые описаны в предыдущем разделе.
/openvpn/bin/hosts.rb

#!/usr/bin/ruby
# -*- coding: utf-8 -*-
require 'pp'

def log(string)
  puts 'hosts.rb: ' + string
end

def parse_config_file(name)
  config_path = "hosts/#{name}"

  unless File.exist?(config_path)
    puts "There is no specific configuration for #{name}."
    p name
    exit 0
  end

  config_source = IO.read(config_path).split("\n")

  config = config_source.inject([]) do |result,line|
    ip, port, protocol = line.split(/\s+/)
    result << {
      ip: ip,
      port: port,
      protocol: protocol || 'tcp'
    }
  end
end

def get_config(name)
  user_config = parse_config_file(name)
  if user_config
    everybody_config = parse_config_file('everybody')
  end
  everybody_config + user_config
end

def apply_rule(rule)
  command = "sudo iptables #{rule}"
  log(command)
  system(command)
end

def remove_rule(number)
  command = "sudo iptables -D FORWARD #{number}"
  log(command)
  system(command)
end

def allow_target(source_ip, options)
  # Разрешить для клиента доступ к конкретному порту конкретного хоста.
  apply_rule("-A FORWARD -s #{source_ip} -i tun0 -d #{options[:ip]} -p #{options[:protocol]} --dport #{options[:port]} -j ACCEPT")
  # Разрешить для клиента пинговать конкретный хост
  apply_rule("-A FORWARD -s #{source_ip} -i tun0 -d #{options[:ip]} -p icmp --icmp-type echo-request -j ACCEPT")
end

def clear_targets(source_ip)
  # Удалить все правила из таблицы FORWARD, содержащие source_ip.

  rules_exist = true

  while rules_exist

    table = `sudo iptables -L FORWARD --line-number`.split("\n")

    the_line = table.find do |line|
      fields = line.split(/\s+/)
      ip = fields[4]
      ip == source_ip
    end

    if the_line
      number = the_line.split(/\s+/)[0]
      remove_rule(number)
    else
      rules_exist = false
    end

  end

end

################################################################################

script_type = ENV['script_type']
log(script_type)

name      = ENV['common_name']
source_ip = ENV['ifconfig_pool_remote_ip']

case script_type
when 'client-connect'
  config = get_config(name)
  config.each{|target| allow_target(source_ip, target)}
when 'client-disconnect'
  clear_targets(source_ip)
else
  puts "Unknown script type #{script_type}."
end

Правила хранятся в файлах, соответствующими common name сертификатов в папке /etc/openvpn/hosts. В них прописаны какие именно IP-адреса доступны для конкретного клиента. Разделитель — произвольное количество пробелов. Через разделитель записываются ip-адрес, порт и протокол (tcp или udp).

10.0.0.24  53 udp
10.0.0.25  53 udp
10.0.2.3  443 tcp

В результате в папке /etc/openvpn должна получиться следующая структура

├── bin

│ └── hosts.rb

├── hosts

│ ├── user1

│ ├── user2

│ └── everybody

├── server.conf

└──…

User1 и user2 — это файлы в вышеприведенном формате. Они описывают к каким хостам у пользователя с соответствующим common name есть доступ.

Есть еще один дополнительный файл everybody, в нем лежат правила, _которые применяются ко всем клиентам_, при условии, что для этих клиентов есть отдельный файл конфигурации. То есть, если для пользователя указан список хостов, куда ему можно ходить, тогда применяется этот список и те хосты, которые перечислены в everybody. Если нет, тогда everybody не применяется. В этот файл удобно выносить например DNS-сервера.

Логирование

Скрипт установки включает только логирование текущих соединений (параметр status). Чтобы появился обычный лог нужно дописать строчку в конфиг сервера (/etc/openvpn/server.conf):

log-append /var/log/openvpn.log

LDAP

Существует плагин openvpn-auth-ldap, который позволяет вторично аутентифицировать пользователя через LDAP.

Поставить пакет:

sudo yum install openvpn-auth-ldap

Добавить в server.conf:

plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-ldap.so "/etc/openvpn/ldap.conf"

Создать конфиг для ldap в /etc/openvpn/ldap.conf:

<LDAP>
  URL              ldaps://{LDAP_DOMAIN_HERE}
  Timeout          15
  TLSEnable        no
  FollowReferrals  yes

  BindDN           "BIND_DN_HERE"
  Password         "BIND_PASSWORD_HERE"
</LDAP>

<Authorization>
  BaseDN           "{BASE_DN_HERE}"
  SearchFilter     "(&(sAMAccountName=%u)(objectClass=organizationalPerson)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"
  RequireGroup     false
</Authorization>

Добавить в пользовательский ovpn-конфиг строчку:

auth-user-pass

Таким образом у пользователя сначала спросят логин и пароль из домена, потом PIN-код от токена. Если один из этих шагов не пройдет, подключение не будет установлено.

Описание опций для ldap.conf есть в репозитории плагина. Он поддерживает аутентификацию по членству в группе, но я это не тестировал.

Скорость

Наибольший прирост скорости дает включение udp режима. Это советуют во всех мануалах. Смысл в том, что нет смысла запускать клиентское tcp-подключение в tcp канале. Одного tcp у клиента достаточно, чтобы производить корректную доставку пакетов. Если в udp-канале будут пропадать пакеты, то корректировку доставки будет контролировать клиентское tcp-соединение.

Скорость возрастет как минимум потому что не надо ждать подтверждения доставки каждого пакета в канале. С tcp есть вторая проблема — один клиентский tcp пакет скорее всего не влезает в один пакет vpn-канала. MTU совпадает, но к клиентскому пакету нужно еще добавлять заголовки. В результате на один пользовательский пакет приходится отсылать два пакета внутри vpn-канала.

TCP имеет смысл использовать когда по-другому нельзя. Например, когда vpn работает через ssh канал.

Пример полного конфига сервера

example-server.conf

port 1194
proto tcp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-auth ta.key 0
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.0.0.25"
push "dhcp-option DNS 10.0.0.24"
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

log-append /var/log/openvpn.log

script-security 2
client-connect    /etc/openvpn/bin/hosts.rb
client-disconnect /etc/openvpn/bin/hosts.rb

Настройка токенов

Библиотека PKCS#11

Для работы с токенами нужна специальная библиотека. Библиотека нужна как для создания ключевых пар, так и для собственно подключения. Скачать под все платформы можно по ссылке.

Везде, где дальше встречается librtpkcs11ecp.so — это и есть та самая библиотека, которую надо скачать и положить куда-нибудь в удобное место.

Создание сертификата на токене

Сгенерировать на токене ключевую пару. Параметр id здесь — это порядковый номер слота на токене, куда укладываются ключевая пара.

pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so --keypairgen --key-type rsa:2048 -l --id 01

Сделать для публичного ключа запрос на сертификат. В процессе создание запроса на сертификат устанавливается срок жизни сертификата и common name, который используется для фильтрации доступных ip-адресов внутри сети. Common name должен соответствовать логину в ActiveDirectory, чтобы не было путаницы.

openssl
openssl> engine -t dynamic -pre SO_PATH:/usr/lib64/openssl/engines/pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib64/librtpkcs11ecp.so
openssl> req -engine pkcs11 -new -key slot_0-id_01 -keyform engine -out /home/john/good.req

Полученный запрос нужно перенести в папку /etc/openvpn/easy-rsa/pki/reqs/. Расширение у файла обязательно должно быть req.
Преобразование запроса в сертификат:

cd /etc/openvpn/easy-rsa/
./easyrsa sign-req client good

После этого в папке /etc/openvpn/easy-rsa/pki/issued/ появится сертификат с тем же именем, но расширением crt.

Перед записью сертификат нужно сконвертировать в DER:

openssl x509 -in /home/user/user-cert.pem -out /home/user/user-cert.crt -outform DER

Запись сертификата на токен:

pkcs11-tool --module /usr/lib/librtpkcs11ecp.so -l -y cert -w /home/user/user-cert.crt --id 45 --label TEST

Написано на основе статьи «Использование Рутокен ЭЦП с OpenSSL (RSA)».

Использование токена для аутентификации

Найти id сертификата, который нужно предъявить серверу:

$ openvpn --show-pkcs11-ids /usr/lib64/librtpkcs11ecp.so

The following objects are available for use.
Each object shown below may be used as parameter to
--pkcs11-id option please remember to use single quote mark.

Certificate
       DN:             /CN=User1
       Serial:         490B82C4000000000075
       Serialized id:  aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600

Нас здесь интересует serialized id.

Опции, которые надо вписать в ovpn-конфиг, чтобы подцепились токены:

pkcs11-providers /usr/lib64/librtpkcs11ecp.so
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'

Опция pkcs11-id обязательно должна быть заключена в одинарные кавычки.

Эта инструкция имеет смысл на всех платформах. Нужно указать путь до библиотеки и id сертификата на токене. Библиотека может называться немного по-другому, быть .dll, а не .so, но смысл тот же самый.

Из ovpn-файла при этом нужно удалить секции cert и key, потому что сертификат и приватный ключ будут браться с токена.

Полностью клиентский конфиг (для windows) выглядит так:

client.ovpn
client

dev tun

proto tcp

sndbuf 0

rcvbuf 0

remote 78.47.37.247 22222

resolv-retry infinite

nobind

persist-key

persist-tun

remote-cert-tls server

cipher AES-256-CBC

comp-lzo

setenv opt block-outside-dns

key-direction 1

verb 3

pkcs11-providers "c://Windows//System32//rtPKCS11ECP.dll"

pkcs11-id 'Aktiv\x20Co\x2E/Rutoken\x20ECP/342b871d/Rutoken/01'

-----BEGIN CERTIFICATE-----

{CERT_HERE}

-----END CERTIFICATE-----

<tls-auth>

#

# 2048 bit OpenVPN static key

#

-----BEGIN OpenVPN Static key V1-----

{KEY_HERE}

-----END OpenVPN Static key V1-----

</tls-auth>

Написано на основе «How to add dual-factor authentication to an OpenVPN configuration using client-side smart cards».

Настройка клиентов

Linux

В openvpn есть баг, который не дает пользователю ввести PIN-код от токена, если пакет собран с поддержкой systemd. Поскольку в последнее время systemd есть везде, все пакеты, которые уже доступны в репозиториях собраны с его поддержкой. Клиентам на линуксе нужно собирать пакет самостоятельно. Вот пример конфигурации, которая заработала у меня на Arch Linux:

./configure \
        --prefix=/usr \
        --sbindir=/usr/bin \
        --enable-iproute2 \
        --enable-pkcs11 \
        --enable-plugins \
        --enable-x509-alt-username

Проверить собран openvpn с systemd или без него можно следующей командой:

openvpn --version | grep --color enable_systemd

Mas OS

Под Mac OS есть только один бесплатный клиент — Tunnelblink.

Он не умеет из gui вводить pin-код от токена. Баг описан например здесь — https://groups.google.com/forum/#!topic/tunnelblick-discuss/f_Rp_2nV-x8 Обходится запуском openvpn из консоли. Это не удивительно, учитывая то, что официальный клиент под windows этого тоже не умеет.

Так же под Mac OS (в отличии от windows) необходимы дополнительные скрипты для настройки сети. Если просто запускать openvpn из консоли, то не будет работать DNS (может быть что-то еще, проявился только DNS).

В TunnelBlick есть эти скрипты настройки сети, их только нужно вызвать при установлении и разрыве соединения. Что нужно дописать в ovpn-конфиг:

script-security 2
up   "/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw"
down "/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw"

Пример скрипта для запуска openvpn-подключения, который можно положить на рабочий стол и тыкать мышкой:

#!/bin/bash

tunnelblick=/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.2-openssl-1.0.2k
sudo $tunnelblick/openvpn --config $tunnelblick/user.ovpn

Windows

Под windows все вроде работает. Официальный клиент не умеет вводить pin-код от токена, обходится через запуск openvpn руками из консоли.

Самое главное — все делать из под администратора. Запускать от администратора установщик клиента. Запускать терминал в котором стартуется openvpn тоже с правими админа, иначе он не сможет управлять сетевым интерфейсом.

Под виндой путь до библиотеки для работы с токенами должен записываться через двойные слеши. Это касается как ovpn-конфига так и опции --show-pkcs11-ids в командной строке.

pkcs11-providers "c://Windows//System32//rtPKCS11ECP.dll"
pkcs11-id 'Aktiv\x20Co\x2E/Rutoken\x20ECP/342b871d/Rutoken/01'

OpenVPN 2.4+ личный гайдлайн: rustedowl — LiveJournal

Первый конфиг — серверный. У меня он выглядит так:

#
# Секция параметров OpenVPN
#

# Общие настройки сервера
mode server ;указание на то, что демон OpenVPN будет ожидать подключений
proto udp4 ;протокол — UDP, используется только IPv4
port 1194 ;порт, по которому ожидаются соединения
server 172.16.1.0 255.255.255.0 ;пул адресов, из которого выдаются IP-адреса клиентам, не имеющим статического, заданного ccd
topology subnet ;кому интересно нафига оно — идут сюда
dev tun ;какой тип виртуального адаптера использовать. TUN — это OSI L3, IP-пакеты. TAP — это OSI L2, Ethernet-кадры.
# Что из этого лучше зависит от того, что вам нужно. Кратко: TAP бриджуется и позволяет слать внутри туннеля любые протоколы, однако имеет оверхед за счет Ethernet-заголовков у каждого пакета, плохо масштабируется, не работает с Android (ну разве что у вас есть рут)
# TUN не перекидывает broadcast-трафик, не бриджуется, позволяет слать внутри туннеля только IPv4 и IPv6, зато использует меньше трафика за счет отсутствия оверхеда
# Подробнее можно почитать тут
keepalive 15 45 ;суть — каждые 15 секунд OpenVPN шлет пакет keepalive, если в течении 45 секунд (3х пакетов) ничего не вернулось, то клиент считается упавшим
client-config-dir ccd ; директория (относительно файла сервера, либо надо указать абсолютный путь) в которой хранятся конфиги клиентов
ccd-exclusive ;опция, треубющая наличие ccd-файла для успешного подключения. Есть файл — подключится, нет файла — отлуп.
client-to-client ;опция, разрешающая клиентам видеть друг друга средствами самого OpenVPN. Соединения все равно будут идти через сервер
compress lz4-v2 ;сжатие трафика в туннеле (ВНИМАНИЕ: lz4-v2 ТОЛЬКО для OpenVPN старше 2.4!) Мнения тут расходятся. С одной стороны, если в туннеле бегает исключительно шифрованный трафик, то мы создаем лишнюю нагрузку на сервер. С другой стороны, при этом всегда сжимаются заголовки пакетов, что может дать некоторую экономию. Так же опция где-то на 1мс повышает время прохождения пакета через туннель, относительно этого же времени вне туннеля. Как обычно, решайте сами. Если не нужно — можно указать «none» или удалить строку целиком

# Ускорение (Linux-only) ;очень черная и экспериментальная магия. Вторая опция работает только если протокол — UDP
#txqueuelen 300
#fast-io

# Management Interface ; настройки взаимодействия с менеджмент-интерфейсом OpenVPN. Позволяет управлять демоном через telnet, и умеет много чего. За уточнение по этому поводу спасибо klink0v
management 127.0.0.1 7505
management-query-passwords
auth-retry interact

# Логирование и внешние файлы
ifconfig-pool-persist 2018_UDP_Pool.txt ;в этом файле хранятся адреса, выданные внутренним DHCP OpenVPN клиентам, у которых такие адреса не заданы жестко
log-append 2018_UDP.log ;в этом файле хранится лог
status 2018_UDP_Status.log 10 ;в этом файле хранится текущий статус сервера — сколько работает, какие клиенты подключены. Последняя цифра означает, что обновляется этот файл раз в 10 секунд
status-version 3 ;что именно указывается в предыдущем файле. 3 — это для OpenVPN старше 2.4.0, максимум данных и они удобно отформатированы
verb 3 ;насколько подробным должен быть лог

# Настройки безопасности демона
persist-key ;не перечитывать ключи при мягких перезапусках OpenVPN. Подробнее можно смотртеь тут
persist-tun ;не переоткрывать устройство TUN/TAP при мягких перезапусках OpenVPN, подробнее там же
auth-nocache ;не хранить пароли в памяти, подробнее там же
#mlock ;linux-only опция, при включении которой ключи в памяти никогда не будут записаны на диск
#user nobody ;тоже linux-only, задание пользователя и группы под которыми будет работать OpenVPN после инициализации
#group nogroup

# Улучшение работы на Linux-машинах (https://habrahabr.ru/post/246953/)
sndbuf 393216
rcvbuf 393216

# Настройки шифрования
auth SHA256 ;алгоритм подписи, выбранный для сертификатов при их генерации
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 ;алгоритм шифрования, использующийся во время подключения и согласования симметричного ключа. Если вы выбрали эллиптику для ключей, то посмотрите «Дополнительные материалы» внизу.
cipher AES-256-GCM ;алгоритм шифрования симметричным ключом. По сравнению с AES-128, AES-256 медленнее всего на 15%
ncp-ciphers AES-256-GCM ;новая функция в OpenVPN старше 2.4, позволяющая согласовать более стойкий шифр при соединении, а не взять его из конфига. В старых версиях OpenVPN игнорируется.

# Дополнительная безопасность соединения.
tls-version-min 1.2 ;какую версию TLS использовать при согласовании соединений
remote-cert-tls client ;Подтверждение типа клиентского сертификата, то самое, для чего нужны дополнительные флаги при генерации ключей

#
# Секция сертификатов и ключей
#

# Ключи — Сертификат удостоверяющего центра

<ca>
Сюда просто копируется сертификат CA. Ключи и сертификаты можно интегрировать в конфиг, а можно указывать абсолютный путь к ним в виде файлов. Второй метод более безопасный, поскольку можно назначить права доступа на ключ, но метод интеграции более удобный — все в одном конфиге
</ca>

# Ключи — Сертификат сервера

<cert>
Место для сертификата
</cert>

# Ключи — Закрытый ключ сервера

<key>
Место для закрытого ключа
</key>

# Ключи — Параметры Diffie-Hellman

<dh>
Параметры можно сгенерировать в XCA, «Дополнительно — сгенерировать параметры Диффи-Хэлманна
</dh>

# Ключи — Статический ключ HMAC-фаервола

<tls-crypt>
А вот эта опция интересная. Ключ создается так же, как и старая добрая tls-auth, с помощью команды «openvpn —genkey —secret static.txt», но в отличие от старой опции, которая только подписывала пакеты, эта (поддерживается только с openvpn 2.4.0) их шифрует.
А это значит, что никакие DPI не смогут понять, что пересылаемый трафик принадлежит OpenVPN, в то время как раньше отловить характерные для OpenVPN пакеты не составляло никакого труда. Как и заблочить это на взлете
Естественно, как и tls-auth, tls-crypt защищает от DoS-атак.
</tls-crypt>

Теперь — Client Config Directory, оно же CCD
Это механизм, который дает OpenVPN ту невероятную гибкость, которую так любят многие администраторы. Суть в том, что для каждого клиента можно настроить не только выдаваемый ему статический адрес, но и спускаемые маршруты, DNS-сервера, search domain, выполняемые команды и много других вещей, ради которых стоит почитать man.
CCD должен называться так же, как и common name клиента. Если файл CCD пуст, то OpenVPN лишь позволит аутентифицироваться клиенту, и выдаст ему IP-адрес из заданного параметром server пула адресов.
Обычно я вношу туда только одну команду — «ifconfig-push 172.16.1.2 255.255.255.0», то есть задаю клиенту статический адрес.
Еще одна важная особенность — по умолчанию CCD дополняют те опции, что есть в основном файле конфига. Т.е. если у вас в конфиге сервера написано:
push «route 192.168.0.0 255.255.255.0 172.16.1.2», а в CCD «192.168.1.0 255.255.255.0 172.16.1.2», то клиент получит оба маршрута. Если нужно, чтобы CCD перезаписывал параметры конфига, в первой строке CCD надо написать push-reset

Почему OpenVPN не может сделать TLS? — Хабр Q&A

Привет всем, такая вот проблема поставил сервер OpenVPN для себя , нашел даже скрипт автоустановки (Но уже и вариант вручную без скриптов тоже пробовал) но все одно к одному в итоге не получается пройти TLS рукопожатие у клиента в ошибке

Fri May 01 20:05:52 2020 TLS: Initial packet from [AF_INET]тут_ип_моего_сервера:13555, sid=ae9503b4 52f4177f
Fri May 01 20:06:52 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri May 01 20:06:52 2020 TLS Error: TLS handshake failed

Что пробовал делать, включал net ipv4 forward в sysctl.conf, переустанавливал openvpn с нуля раз 5, делал по разным абсолютно инструкциям в том числе через пару скриптов авто установки. Сам процесс такой я ставлю сервер, делаю ключи, делаю клиенту ключи пытаюсь соединиться, соединение начинается но на моменте TLS ошибка.

Вот конфиг сервера

server.conf

local тут внешний ip адрес сервера
port 13555
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
duplicate-cn
auth SHA512
tls-auth ta.key 0
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
#push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
#fragment 1200
#mssfix 1200
cipher AES-256-CBC
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 10
log openvpn-log.log
#crl-verify crl.pem

вот конфиг клиента
client.ovpn

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote тут_внешний_Ip_моего_сервера 13555
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
setenv opt block-outside-dns
key-direction 1
verb 3

Вот log OpenVPn при verb 10
https://pastebin.com/yKa1qe1h

Вот мой iptables

# Generated by iptables-save v1.4.21 on Fri May  1 20:17:11 2020
*mangle
:PREROUTING ACCEPT [16769:4887526]
:INPUT ACCEPT [16769:4887526]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [25942:23122279]
:POSTROUTING ACCEPT [25942:23122279]
COMMIT
# Completed on Fri May  1 20:17:11 2020
# Generated by iptables-save v1.4.21 on Fri May  1 20:17:11 2020
*filter
:INPUT DROP [90:4759]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [15067:8176131]
:XL-Firewall-1-INPUT - [0:0]
:vesta - [0:0]
-A INPUT -p udp -m udp --dport 13555 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s мой_внешний_ip/32 -j ACCEPT
-A INPUT -s 127.0.0.1/32 -j ACCEPT
-A INPUT -p udp -m udp --dport 13555 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22,38022 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 21,12000:12100 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 25,465,587,2525 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 110,995 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 143,993 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 3306,5432 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8083 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT
COMMIT
# Completed on Fri May  1 20:17:11 2020
# Generated by iptables-save v1.4.21 on Fri May  1 20:17:11 2020
*nat
:PREROUTING ACCEPT [23:1004]
:INPUT ACCEPT [20:860]
:OUTPUT ACCEPT [4:240]
:POSTROUTING ACCEPT [4:240]
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source мой_внешний_ip
COMMIT
# Completed on Fri May  1 20:17:11 2020

В итоге порт UDP открыт, SNAT сделан чтобы был доступ в интернет, но именно на TLS затык. Но есть одно НО в пользу того что указанное вроде должно работать, в какой-то момент при сохранении изменений в iptables кажется прошел TLS, и все соединенилось, я подключился получил ip 10.8.0.2 проверил ping все работает действительно через сервер и до google, но стоило нажать переподключиться как все перестало работать и вновь ошибка при TLS и вот я уже 2 дня вожусь с этим, просто идеи уже закончились в чем же может быть дело. Уже и проверял вообще мой домашний ПК подключается ли к VPN’ам на всякий случай, все нормально подключился к публичному VPN серверу. Есть еще идеи?

Авторизация по клиентским TLS/SSL сертификатам в NGINX — Geek Notes

Простой и удобный способ авторизации на сайте или в приложениях по клиентским TLS/SSL сертификатам.

Данный вид аутентификации может пригодиться при ограничении доступа к конфиденциальным страницам, админ-панели сайта или для авторизации веб-приложений.

Шаг 1. Создание центра сертификации

Чтобы приступить к работе сперва необходимо настроить центр сертификации (CA), это довольно просто. Если на сервере установлен OpenSSL, то СА по умолчанию настроен и готов к работе. Теперь создадим свой собственный доверенный сертифика, он необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером.

Шаг 1.2. Создаем приватный ключ центра сертификации.

openssl genrsa -out ca.key 4096

Шаг 1.3. Создаем самоподписанный сертификат.

openssl req -new -sha256 -x509 -days 1095 -key ca.key -out ca.crt

Шаг 2. Создание сертификата сервера

Шаг 2.1 Создаем приватный ключ для веб-сервера.

openssl genrsa -out server.key 4096

Шаг 2.2. Создаем сертификат для веб-сервера.

openssl req -new -key server.key -sha256 -out server.csr

Шаг 2.3. Подписываем сертификат веб-сервера нашим центром сертификации.

openssl x509 -req -days 1095 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 0x`openssl rand 16 -hex` -sha256 -out server.pem

Шаг 3. Создание клиентского сертификата

Шаг 3.1. Создаем клиентский приватный ключ по тому же принципу.

openssl genrsa -out client.key 4096

Шаг 3.2. Создаем клиентский сертификат.

openssl req -new -key client.key -sha256 -out client.csr

Шаг 3.3. Подписываем сертификат нашим центром сертификации.

openssl x509 -req -days 1095 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 0x`openssl rand 16 -hex` -sha256 -out client.pem

Шаг 4. Создание сертфиката в формате PKCS#12 для браузеров.

openssl pkcs12 -export -in client.pem -inkey client.key -name "Sub-domain certificate for some name" -out client.p12

Добавляем сертификаты в систему на примере MacOS

Загружаем client.p12 и установим его в систему.

Переходим в связку ключей и в свойствах установленного сертификата меняем уровень доверия на “Всегда доверять”.

Раскрываем ветку сертификата и предоставляем полный доступ для программ в его свойствах:

Для того, чтобы соединение было доверенным между сервером и клиентом, то обязательно установим корневой сертификат на клиентское устройство (ca.crt)

Сертификаты

TLS — методы аутентификации

Метод аутентификации cert позволяет аутентификацию с использованием клиентских сертификатов SSL / TLS
которые либо подписаны центром сертификации, либо самоподписаны.

Доверенные сертификаты и центры сертификации настроены непосредственно для метода аутентификации
используя путь certs / . Этот метод не может читать доверенные сертификаты из
внешний источник.

Сертификаты CA связаны с ролью; имена ролей и имена CRL нормализованы к
строчные.

Обратите внимание, что для использования этого метода аутентификации tls_disable должно иметь значение false в Vault
конфигурация.Это связано с тем, что сертификаты отправляются через саму связь TLS.

»Проверка отзыва

Начиная с Vault 0.4, этот метод поддерживает проверку отзыва.

Авторизованный пользователь может отправлять CRL в формате PEM, идентифицированные заданным именем;
они могут быть обновлены или удалены по желанию. (Примечание: Vault не извлекает списки отзыва сертификатов ;
сами списки отзыва сертификатов и любые обновления должны быть при желании помещены в хранилище,
например, через задание cron , которое извлекает их из источника и помещает в
Свод.)

При наличии CRL во время аутентификации клиента:

• Если клиент представляет любую цепочку, в которой ни один сертификат в цепочке не соответствует
  отозванный серийный номер, аутентификация разрешена

• Если нет цепи, представленной клиентом без отозванного серийного номера,
  в аутентификации отказано

Этот метод обеспечивает хорошую безопасность, а также обеспечивает гибкость. За
Например, если промежуточный ЦС будет удален, клиент может быть
настроен с двумя цепочками сертификатов: одна, содержащая начальный
промежуточный ЦС в пути и другой, содержащий замену.когда
исходный промежуточный CA отменяется, цепочка, содержащая замену
по-прежнему позволит клиенту успешно пройти аутентификацию.

N.B. : Соответствие выполняется только по серийному номеру . Для большинства центров сертификации
включая метод Vault pki , несколько списков отзыва сертификатов могут успешно использоваться как
серийные номера глобально уникальны. Однако, поскольку RFC только указывают, что
серийные номера должны быть уникальными для каждого ЦС, некоторые ЦС выдают серийные номера по порядку,
что может вызвать конфликты при попытке использовать списки отзыва сертификатов от двух таких центров сертификации в одном
крепление метода.Обходной путь здесь — смонтировать несколько копий
cert , настройте каждый с одним CA / CRL и попросите клиентов подключиться к
соответствующее крепление.

Кроме того, поскольку метод не извлекает сами списки отзыва сертификатов, списки отзыва сертификатов
назначенное время до следующего обновления не считается. Если CRL больше не используется,
Администратор должен удалить его из метода.

»Аутентификация

» Через интерфейс командной строки

Нижеприведенная аутентификация выполняется по роли сертификата web путем представления сертификата
( сертификат.pem ) и ключ ( key.pem ), подписанный центром сертификации, связанным с сертификатом web
роль. Обратите внимание, что имя web связано с приведенным ниже примером конфигурации.
по пути auth / cert / certs / web . Если имя роли сертификата не указано,
метод аутентификации будет пытаться аутентифицироваться по всем доверенным сертификатам.

ПРИМЕЧАНИЕ Значение -ca-cert , используемое здесь, предназначено для ЦС прослушивателя TLS Vault.
сертификат, а не ЦС, выдавший сертификат проверки подлинности клиента.Эта
может быть опущен, если ЦС, использованный для выдачи сертификата сервера Vault, является доверенным.
локальной системой, выполняющей эту команду.

  $ вход в хранилище \
    -method = cert \
    -ca-cert = хранилище-ca.pem \
    -client-cert = cert.pem \
    -client-key = key.pem \
    имя = Интернет
  

»Через API

Конечная точка для входа — / логин . Клиент просто подключается к своему
Сертификат TLS, и когда конечная точка входа в систему будет достигнута, метод аутентификации будет
определить, существует ли соответствующий доверенный сертификат для аутентификации клиента.При желании вы можете указать одну роль сертификата для аутентификации.

ПРИМЕЧАНИЕ Значение --cacert , используемое здесь, предназначено для ЦС прослушивателя TLS Vault.
сертификат, а не ЦС, выдавший сертификат проверки подлинности клиента. Эта
может быть опущен, если ЦС, использованный для выдачи сертификата сервера Vault, является доверенным.
локальной системой, выполняющей эту команду.

  $ завиток \
    --request POST \
    --cacert vault-ca.pem \
    --cert cert.pem \
    - ключевой ключ.pem \
    --data '{"name": "web"}' \
    https://127.0.0.1:8200/v1/auth/cert/login
  

»Конфигурация

Методы аутентификации необходимо настроить заранее, прежде чем пользователи или машины смогут
аутентифицировать. Эти шаги обычно выполняются оператором или конфигуратором.
инструмент управления.

1. Включить метод проверки подлинности сертификата:

     $ vault auth enable cert
     

2. Настройте его с помощью доверенных сертификатов, которым разрешена аутентификация:

     $ vault write auth / cert / certs / web \
       display_name = web \
       политики = Интернет, продукт \
       сертификат = @ веб-сертификат.pem \
       ttl = 3600
     

   Это создает новый доверенный сертификат «Интернет» с тем же отображаемым именем и
   политики «веб» и «прод». Сертификат (открытый ключ), используемый для проверки
   Клиенты предоставляются файлом «web-cert.pem». Наконец, необязательное значение ttl
   может быть предоставлено в секундах, чтобы ограничить продолжительность аренды.

Метод аутентификации сертификата TLS имеет полный HTTP API. Пожалуйста, посмотрите
TLS Certificate API для более подробной информации.

.

php — AUTH TLS / SSL с функцией ftp_connect

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

.

java — Jetty Mutual TLS auth не находит сертификат клиента

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

.

No related posts.