Openconnect client ubuntu настройка
Обновлено: 08.07.2024
При разработке приложения вы разворачиваете промежуточные версии на контуре внутри своей компании. Но у вашего заказчика может быть свой контур за VPN. Это усложняет CI CD.
Сегодня мы разберемся, как подключиться к Cisco VPN используя openconnect.
Openconnect
OpenConnect – это открытое приложение для подключения к виртуальным частным сетям с реализацией подключений точка-точка, которое изначально было написано в качестве замены проприетарного клиента Cisco AnyConnect SSL VPN.
Причиной для разработки OpenConnect послужила серия недостатков, обнаруженных в решении Cisco под Linux:
- отсутствие поддержки архитектур отличных от i386 (для платформ Linux)
- отсутствие интеграции с NetworkManager
- отсутствие грамотной поддержки форматов пакетов RPM и DEB
- невозможность работы в качестве непривилегированного пользователя
- закрытость кода и др.
По какой-то причине у меня не получилось настроить соединение через AnyConnect, зато получилось через openconnect 😄
Также вам может понадобиться vpn-slice, который есть только для openconnect. Речь о vpn-slice пойдет дальше.
Все манипуляции проводятся на CentOS 7. Для начала устанавливаем openconnect.
После этого вы уже можете подключиться к vpn
Часто в корпоративных организациях используется прокси, тогда поможет флаг -P . При этом флаг -b после успешного соединения убирает его в фон, чтобы вы могли продолжать пользоваться сервером.
Нужно будет ввести данные для входа в VPN, после чего вы успешно подключитесь. Но есть одна проблема.
Для отключения от VPN используйте эту команду:
Перезапись resolv.conf
Ваш файл /etc/resolv.conf будет перезаписан. Из-за этого мы потеряли доступ к сети и выход в интернет.
Эту проблему решает библиотека vpn-slice. Установить ее проще всего через pip3.
Вы должны установить vpn-slice как root, потому что openconnect или vpnc должны будут иметь возможность вызывать vpn-slice во время работы как root. Например для изменения /etc/hosts
После этого можно подключиться к впн, при этом указав нужные хосты.
- 21.16.41.48 – ip нужного вам сервера за vpn.
- 21.16.41.49 – второй нужный вам сервер.
Таким образом мы подключились к VPN, и получили доступ только не обходимым нам серверам.
Непрерывное подключение к Cisco AnyConnect VPN
Мне нужно было поддерживать почти непрерывное VPN-соединение с сервером с другого сервера. Сервер 1 был частью сети, которая обеспечивала защищенный доступ VPN к внешним соединениям через Cisco Anyconnect.
Для этого я использую OpenConnect для подключения к серверу и сценарий bash для непрерывной проверки соединения и, если он отключен, для повторного подключения.
Обратите внимание, что в приведенном ниже подходе пароль vpn хранится в виде открытого текста в файле sh, что представляет потенциальную угрозу безопасности. Сценарий должен быть заблокирован, чтобы пользователи без авторизации не могли просматривать его содержимое.
Следовательно, этот подход может быть подходящим только для сервера, которые строго управляются или не доступны другим пользователям.
Создадим скрипт, который:
- Подключится к VPN;
- Каждые n секунд проверяет, подключен ли он
- Подключается к VPN, если соединение прервано
В приведенном ниже примере мы создадим сценарий vpn.sh.
Не забудьте заменить переменные в строке 15 на свои.
Используйте свою команду sudo openconnect для подключения. Выше приведена команда для примера, возможно она вам не подойдет.
Давайте хотя бы заблокируем этот файл, чтобы он был доступен для чтения только root:
Запуск скрипта в фоновом режиме.
Как только вы отладите свой скрипт, вы можете запустить его как фоновый скрипт:
Остановка фонового скрипта.
Используйте ps , чтобы найти PID сценария VPN и процесса openconnect:
Хотите использовать линукс на работе, но корпоративный VPN не даёт? Тогда эта статья может помочь, хотя это не точно. Хочу заранее предупредить, что вопросы администрирования сетей я понимаю плохо, поэтому не исключено, что я всё сделал неправильно. С другой стороны не исключено, что я смогу написать руководство так, что оно будет понятно обычным людям, так что советую попробовать.
В статье много лишней информации, но без этих знаний я бы не смог решить проблемы, которые у меня неожиданно появлялись с настройкой vpn. Думаю, что у любого, кто попытается применить это руководство, возникнут проблемы, которых у меня не было, и надеюсь, что эта лишняя информация поможет эти проблемы самостоятельно решить.
Большинство команд, используемых в руководстве нужно выполнять через sudo, который для краткости убран. Имейте в виду.
Большинство ip адресов подверглись жестокой обфускации, поэтому если видите адрес наподобие 435.435.435.435 — там должен быть какой-то нормальный ip, специфичный для вашего случая.
У меня Ubuntu 18.04, но думаю с небольшими правками руководство можно применять и к другим дистрибутивам. Однако в этом тексте линукс == Ubuntu.
Cisco Connect
Те, кто сидит на Windows или MacOS могут подключиться к нашему корпоративному VPN через Cisco Connect, которому нужно указать адрес гейтвея и при каждом подключении вводить пароль, состоящий из фиксированной части и кода, генерируемого Google Authenticator.
В случае с Линуксом, завести Cisco Connect не получилось, зато получилось нагуглить рекомендацию использовать openconnect, сделанный специально для того, чтобы заменить Cisco Connect.
Openconnect
По идее в убунте есть специальный графический интерфейс для openconnect но у меня он не заработал. Может оно и к лучшему.
В убунте openconnect ставится из пакетного менеджера.
Сразу после установки можно попробовать подключиться к VPN
openconnect попросит ввести пароль, который, напомню, состоит из фиксированной части и кода из Google Authenticator, а потом попробует подключиться к vpn. Если получилось, поздравляю, можете смело пропускать середину в которой много боли и переходить к пункту про работу openconnect в фоне. Если не заработало, то можно продолжать. Хотя если получилось при подключении например с гостевого вайфая на работе, то возможно радоваться и рановато, надо попробовать повторить процедуру из дома.
Cертификат
С высокой вероятностью ничего не запустится, а выхлоп openconnect будет выглядеть как-то вот так:
Тут сервер отослал нам сертификат, по которому можно определить, что подключение происходит именно к серверу родной корпорации, а не к злобному мошеннику, а системе этот сертификат неизвестен. И поэтому она не может проверить, настоящий сервер или нет. И поэтому на всякий случай прекращает работу.
Для того, чтобы openconnect всё-таки подключился к серверу, нужно явным образом сказать ему, какой сертификат должен прийти от VPN сервера с помощью помощью ключа --servercert
А узнать какой сертификат нам отослал сервер можно прямо из того, что напечатал openconnect. Вот из этого куска:
Вот такой командой можно попробовать подключиться ещё раз
Возможно теперь заработало, тогда можно переходить к концу. Но лично мне Убунта показала фигу вот в такой форме
Что тут произошло, мне не понятно. Но эксперимент показывает, что если добавить в /etc/resolv.conf строку
то адреса внутри VPN начнут магическим образом ресолвиться и по ним можно будет ходить, то есть то, что ищет какими DNS ресолвить адреса, смотрит именно в /etc/resolv.conf, а не куда-то ещё.
Что подключение к VPN есть и оно работает, можно убедиться и без правок в /etc/resolv.conf, для этого достаточно ввести в браузере не символьное имя ресурса из vpn, а его ip адрес
По итогу получается две проблемы
- при подключении к VPN не подхватывается её dns
- весь трафик идёт через vpn, который не позволяет ходить в интернет
Что делать я сейчас расскажу, но сначала немного автоматизации.
Автоматический ввод фиксированной части пароля
К текущему моменту вы скорее всего уже ввели пароль не менее пяти раз и эта процедура вас уже изрядно утомила. Во-первых, потому что пароль длинный, во-вторых потому что при вводе нужно уложиться в фиксированный временной промежуток
Окончательное решения проблемы в статью не вошло, но можно сделать так, чтобы фиксированную часть пароля не пришлось вводить по многу раз.
Положим, фиксированная часть пароля — fixedPassword, а часть из Google Authenticator 567 987. Весь пароль целиком openconnect можно передать через стандартный ввод с помощью аргумента --passwd-on-stdin .
Теперь можно постоянно возвращаться к последней введённой команде и менять там только часть из Google Authenticator.
Корпоративный VPN не позволяет ходить в интернет.
Вообще не очень неудобно, когда для того, чтобы сходить на хабр приходится использовать отдельный компьютер. Отсутствие возможности копипастить со stackoverfow, вообще может парализовать работу, поэтому что надо что-то делать.
Нужно как-то организовать, чтобы когда надо зайти на ресурс из внутренней сети, линукс ходил в vpn, а когда надо зайти на хабр — ходил в интернет.
openconnect после запуска и установки соединения с vpn, выполняет специальный скрипт, который находится в /usr/share/vpnc-scripts/vpnc-script. В скрипт на вход передаются какие-то переменные, а он делает настройку vpn. К сожалению, я не смог разобраться, как разделить потоки трафика между корпоративным vpn и остальным интернетом с помощью родного скрипта.
Видимо специально для таких как я была разработана утилита vpn-slice, которая позволяет направлять трафик по двум каналам без танцев с бубном. Ну, то есть танцевать придётся, но шаманом при этом быть не обязательно.
Разделение трафика с помощью vpn-slice
Во-первых vpn-slice придётся поставить, с этим придётся разобраться самостоятельно. Если в комментариях будут вопросы, я напишу по этому поводу отдельный пост. Но это обычная программа на питоне, так что сложностей быть не должно. Я ставил с помощью virtualenv.
А дальше утилиту надо применить, с помощью ключа --script указав openconnect, что вместо стандартного скрипта нужно использовать vpn-slice
В --script передаётся строка с командой, которую нужно вызвать вместо скрипта. ./bin/vpn-slice — путь к исполняемому файлу vpn-slice 192.168.430.0/24 — маска адресов, по которым следует ходить в vpn. Тут, имеется в виду что если адрес начинается с 192.168.430 — то ресурс с этим адресом нужно искать внутри vpn
Теперь ситуация должна быть почти нормальной. Почти. Теперь можно зайти на хабр и можно зайти на внутрикорпоративный ресурс по ip, но нельзя зайти на внутрикорпоративный ресурс по символьному имени. Если прописать соответствие символьного имени и адреса в hosts — всё должно заработать. И работать, пока ip не поменяется. Линукс теперь умеет ходить в интернет или во внутрикорпоративную сеть в зависимости от ip. Но для определения адреса по прежнему используется не корпоративный DNS.
Проблема ещё может проявляться в таком виде — на работе всё нормально, а дома на внутрикорпоративные ресурсы можно зайти только по ip. Это потому что когда ты подключен к корпоративному Wi-Fi, то DNS используется тоже корпоративный, и в нём символьные адреса из VPN ресолвятся, несмотря на то что пройти по такому адресу без использования VPN по прежнему нельзя.
Автоматическая модификация файла hosts
Если vpn-slice вежливо попросить, то он может после поднятия VPN сходить в её DNS, найти там ip адреса нужных ресурсов по их символьным именам и вписать их в hosts. После выключения VPN эти адреса будут из hosts удалены. Для этого нужно передать символьные имена в vpn-slice в качестве аргументов. Вот так.
Теперь всё должно работать и в офисе и на пляже.
Искать адреса всех поддоменов в DNS, который отдала VPN
Но теперь, когда мы немного понимаем что к чему эту необходимость можно устранить.
Если после поднятия VPN посмотреть в /etc/hosts, то можно увидеть, вот такую строку
Да и в resolv.conf была добавлена новая строка. Короче, vpn-slice каким-то образом определила где находится dns сервер для vpn.
Я довольно долго гуглил и обнаружил, что такая функциональность есть в убунте из коробки. Имеется в виду возможность использовать для ресолва имён локальный dns сервер dnsmasq.
То есть можно сделать так, чтобы за ip адресами линукс всегда ходил в локальный dns сервер, который в свою очередь, в зависимости от доменного имени, будет искать ip на соответствующем внешнем dns сервере.
Для управления всем, связанным с сетями и сетевыми соединениями, в убунте используется NetworkManager, а графический интерфейс для выбора, например, вайфай соединения — просто фронт к нему.
Нам надо будет полазить в его конфигурации.
- Создать файл в /etc/NetworkManager/dnsmasq.d/evilcorp
- Сказать NetworkManager, что для разрешения имён надо использовать dnsmasq
Конфигурация network-manager находится в /etc/NetworkManager/NetworkManager.conf Надо добавить туда:
Теперь, после подключения к VPN с помощью связки openconnect и vpn-slice, ip будет нормально опредёляться, даже если не добавлять символьные адреса в аргументы к vpnslice.
Как ходить через VPN в отдельные сервисы
После того, как получилось подключиться к vpn, я дня два очень радовался, а потом выяснилось, что если подключаться к впн не из офисной сети, то не работает почта. Симптом знакомый, не правда ли?
Ну а в офисе всё равно используется DNS, в котором этот адрес есть. То есть я так думал. На деле после добавления в dnsmasq строки
ситуация никак не изменилась. ip остался тот же. Пришлось мне ходить на работу.
И уже потом, когда я углубился в ситуацию и немного разобрался в проблеме, один умный человек подсказал мне как её решить. Нужно было подключаться к почтовому серверу не просто так, а через vpn
Я использую vpn-slice, чтобы ходить через VPN по адресам, которые начинаются с 192.168.430. А у почтового сервера не только символьный адрес не является поддоменом evilcorp, у него ещё и ip адрес не начинается с 192.168.430. И из общей сети он конечно никого к себе не пускает.
Для того, чтобы линукс ходил через VPN и к почтовому серверу, нужно добавить в vpn-slice и его. Допустим адрес почтовика- 555.555.555.555
Скрипт для поднятия VPN с одним аргументом
Всё это, конечно, не очень удобно. Да, можно сохранить текст в файлик и копипастить в консольку, а не набирать руками, но всё равно приятного мало. Для облегчения процесса можно завернуть команду в скрипт, который будет находиться в PATH. И тогда нужно будет только ввести код, полученный из Google Authenticator
Если поместить скрипт в connect
то можно будет просто писать в консоли
Но теперь всё равно придётся зачем-то держать консоль в которой запущен openconnect открытой
Запуск openconnect в фоне
К счастью авторы openconnect позаботились о нас и добавили в программу специальный ключ --background, который делает так, чтобы программа после запуска работала в фоне. Если запустить её вот так, то консоль после запуска можно закрыть
И вот, получается, что openconnect работает где-то там в фоне и никому не мешает, но как его остановить непонятно. То есть можно, конечно отфильтровать выхлоп ps грепом и искать процесс в названии которого есть openconnect, но это как-то муторно. Спасибо авторам, которые подумали и об этом. В openconnect есть ключик --pid-file, с помощью которого можно проинструктировать openconnect писать идентификатор своего процесса в файл.
Теперь всегда можно прибить процесс командой
Если процесса нет, kill ругнётся, но ошибку не кинет. Если файла нет, то тоже не случится ничего страшного, так что можно смело убивать процесс в первой строке скрипта.
Теперь можно включить компьютер, открыть консоль и запустить команду, передав ей код из Google Authenticator. Консоль потом можно прибить.
Понять, как жить без vpn-slice оказалось очень сложно. Пришлось много читать и гуглить. К счастью, когда столько времени провёл с проблемой, технические мануалы и даже man openconnect читаются как захватывающие романы.
В итоге я выяснил, что vpn-slice, как и родной скрипт, для разделения сетей модифицирует таблицу маршрутизации.
Таблица маршрутизации
Это, упрощённо говоря, такая таблица в первой колонке которой содержится с чего должен начинаться адрес, по которому хочет пройти линукс, а во второй через какой сетевой адаптер по этому адресу пройти. На самом деле колонок больше, но сути это не меняет.
Для того, чтобы посмотреть таблицу маршрутизации нужно выполнить команду ip route
Для VPN линукс сделал виртуальный адаптер — tun0. За то, чтобы трафик для всех адресов начинающихся с 192.168 шёл через него отвечает строка
Ещё посмотреть на текущее состояние таблицы маршрутизации можно с помощью команды route -n (ip адреса талантливо анонимизированы) Эта команда выдаёт результаты в другом виде и вообще deprecated, но её выхлоп часто попадается в мануалах в интернете и надо уметь его читать.
С чего должен начинать ip адрес для маршрута можно понять из комбинации колонок Destination и Genmask. Те части ip адреса, которым в Genmask соответствуют цифры 255, учитываются, а те, где там 0 — нет. То есть комбинация Destination 192.168.0.0 и Genmask 255.255.255.0 означает, что если адрес начинается с 192.168.0, то запрос к нему пойдёт по этом маршруту. А если Destination 192.168.0.0 но Genmask 255.255.0.0, то по этому маршруту пойдут запросы к адресам, которые начинаются с 192.168
Для того, чтобы разобраться, что на самом деле делает vpn-slice я решил посмотреть на состояния таблиц до и после
До включения VPN было так
После вызова openconnect без vpn-slice стало так
А после вызова openconnect в комбинации с vpn-slice вот так
Видно, что если не использовать vpn-slice, то openconnect явным образом пишет, что по всем адресам, кроме отдельно указанных, надо ходить через vpn.
Там рядом сразу указан ещё один путь, который надо использовать, если адрес, по которому пытается пройти линукс не соответствует ни одной маске из таблицы.
Тут уже написано, что в таком случае надо ходить через стандартный адаптер вайфай.
Я полагаю, что путь для VPN используется потому, что он в таблице маршрутизации первый.
И теоретически, если убрать вот этот дефолтный путь из таблицы маршрутизации, то в связке с dnsmasq openconnect должен обеспечивать нормальную работу.
И всё заработало.
Роутинг запросов к почтовому серверу без vpn-slice
Но у меня же есть ещё почтовый сервер с адресом 555.555.555.555, на который тоже надо ходить через vpn. Маршрут до него тоже надо добавить руками.
И вот теперь всё норм. Так что обойтись без vpn-slice таки можно, но уже надо хорошо знать, что делаешь. Я сейчас думаю не добавить ли в последнюю строку родного скрипта openconnect удаление дефолтного маршрута и добавление маршрута для почтовика после подключения к vpn, просто, чтобы движущихся частей в моём велосипеде стало поменьше.
Наверное, кому-то для того, чтобы понять как настроить VPN хватило бы этого послесловия. Но я, пока пытался понять что и как мне делать, прочитал достаточно много таких руководств, которые работают у автора, но почему-то не работают у меня и решил добавить сюда все кусочки, которые нашёл. Я бы чему-то такому очень порадовался.
С тех пор он был перенесен на поддержку Juniper SSL VPN, который теперь известен как Pulse Connect Secure.
В этом руководстве мы рассмотрим установку и использование клиента OpenConnect SSL VPN для подключения к Cisco AnyConnect VPN VPN и Cisco Juniper Pulse Connect Secure.
Возможности OpenConnect SSL Client
С официального сайта OpenConnect SSL Client имеет следующие функции:
Установка клиента OpenConnect SSL в Linux
Давайте теперь посмотрим на различные способы установки OpenConnect SSL Client на ваш любимый дистрибутив Linux:
Установка клиента OpenConnect SSL на Arch Linux
Для пользователей Arch Linux и их производных дистрибутивов вы можете установить openconnect из официальных репозиториев Pacman.
То же самое можно сделать и с помощью yaourt:
Установка клиента OpenConnect SSL на Debian / Ubuntu
Для Debian и его производных установите пакет openconnect с помощью диспетчера пакетов apt.
Установка клиента OpenConnect SSL на CentOS / RHEL
Для CentOS и RHEL пакет openconnect доступен в репозитории epel.
Добавьте репозиторий, затем установите пакет openconnect:
Установка клиента OpenConnect SSL на Fedora
Для Fedora пакет также доступен от epel.
Дело только в том, что имя менеджера пакетов изменяется:
Установка клиента OpenConnect SSL на macOS
Для пользователей MacOS установите пакет openconnect с использованием brew
Как подключиться к SSL VPN Server с помощью Openconnect ( Вручную )
После того, как пакет openconnect был успешно установлен в вашей операционной системе, вы должны быть готовы к подключению к серверу SSL VPN, который может использовать Cisco AnyConnect SSL VPN и Juniper Pulse Connect Secure.
Простое соединение следует за синтаксисом:
Вам будет предложено ввести пароль, см. Пример ниже:
Как подключиться к SSL VPN Server с помощью Openconnect с помощью скрипта Bash
Я написал скрипт bash, чтобы упростить подключение к серверу SSL Autoconnect SSL VPN.
Поместите его в
/ .bashrc в зависимости от вашей оболочки.
Предоставьте правильные переменные и сохраните файл.
Теперь каждый раз, когда вы хотите подключиться к VPN, вызовите функцию по имени:
Juniper Pulse Client
Чтобы подключиться к серверу Pulse Connect Secure, вам необходимо знать SHA-1 своего сертификата.
В этом руководстве вы узнали, как установить и использовать клиент OpenConnect SSL на Linux и macOS.
Дайте мне знать в разделе комментариев, если вы столкнулись с какой-либо ошибкой.
Пишу для себя, чтобы не забыть как делал. 95 % рабочее. На комментарии отвечаю, когда увижу.
понедельник, 8 июля 2019 г.
Установка OpenConnect на Ubuntu 18.04
В данном описании вариант для 1С без перенаправления интернет трафика:
/.ssh/id_rsa
$ chmod 700
PubkeyAuthentication yes
ChallengeResponseAuthentication no
$ sudo systemctl reload sshd
После проверки входа и sudo
Отключить вход root по ssh
$ sudo nano /etc/ssh/sshd_config
$ sudo systemctl restart ocserv
$ sudo cp /lib/systemd/system/ocserv.service /etc/systemd/system/ocserv.service
$ sudo nano /etc/systemd/system/ocserv.service
[Service]
PrivateTmp=true
PIDFile=/var/run/ocserv.pid
ExecStart=/usr/sbin/ocserv --foreground --pid-file /var/run/ocserv.pid --config /etc/ocserv/ocserv.conf
ExecReload=/bin/kill -HUP $MAINPID
$ sudo systemctl daemon-reload
$ sudo systemctl stop ocserv.socket
$ sudo systemctl disable ocserv.socket
$ sudo systemctl restart ocserv.service
$ systemctl status ocserv
$ sudo ocpasswd -c /etc/ocserv/ocpasswd username
Можно проверерять вход с клиента
$ sudo apt install openconnect
$ sudo apt install net-tools
$ route
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 100 0 0 enp0s3
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s3
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3
$ route
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
default 0.0.0.0 0.0.0.0 U 0 0 0 tun0
default _gateway 0.0.0.0 UG 100 0 0 enp0s3
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s3
XXX.XXX.XXX.XXX _gateway 255.255.255.255 UGH 0 0 0 enp0s3
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3
Для адекватной проверки скорости соединения, нужно создать nat до перезагрузки
Узнаем имя сетевого адаптера :
$ ip a
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group
В данном случае ens18:
$ sudo iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE
$ sudo iptables -t nat -L POSTROUTING
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere
$ sudo nano /etc/ocserv/ocserv.conf
$ sudo systemctl restart ocserv
$ sudo nano /etc/ocserv/ocserv.conf
$ sudo apt install gnutls-bin
$ sudo mkdir /etc/ocserv/ssl/
$ cd /etc/ocserv/ssl/
$ sudo certtool --generate-privkey --outfile ca-privkey.pem
$ sudo nano ca-cert.cfg
$ sudo certtool --generate-self-signed --load-privkey ca-privkey.pem --template ca-cert.cfg --outfile ca-cert.pem
$ sudo certtool --generate-privkey --outfile client-privkey.pem
$ sudo nano client-cert.cfg
Скопировать ниже, uid = "username", пользователя созданного выше:
$ sudo certtool --generate-certificate --load-privkey client-privkey.pem --load-ca-certificate ca-cert.pem --load-ca-privkey ca-privkey.pem --template client-cert.cfg --outfile client-cert.pem
$ sudo certtool --to-p12 --load-privkey client-privkey.pem --load-certificate client-cert.pem --pkcs-cipher aes-256 --outfile client.p12 --outder
Читайте также: