Mac os openvpn missing external certificate

Настройка OpenVPN в macOS

Настройка для Tunelblick

Если ваша версия macOS старшее MacOS X Leopard, вы можете воспользоваться клиентом OpenVPN Tunnelblick.
Tunnelblick также работает и на современных версиях macOS. Для настройки работы Tunellblick выполните следующие действия:

1. Скачайте инсталятор Tunelblick Tunnelblick и установите его.

2. Распакуйте конфигурационные файлы, выданные техподдержкой. Вы также можете их скачать в личном кабинете.

3. Откройте файл с конфигурационного файла ovpn в программе Tunnelblick.

4. Выберите в меню Tunelblick пункт Connect config. При запросе логина и пароля, ввести их, взяв из файла pass.txt,
который также был в архиве с конфигурационными файлами.

5. Для проверки работы сервиса, можете обратитесь к странице https://whoer.net/ru. В отчете Вы можете увидеть текущий IP-адрес.
После окончания работы с VPN, кликните в меню Tunelblick выберите Disconnect config.

Настройка для Viscosity

Если у Вас Mac OS X Leopard или новее, наиболее удобной в использовании является клиент OpenVPN Viscosity.
В этом случае настройка VPN-сервиса сводится к следующим действиям:

1. Скачайте последнюю версию программы Viscosity и установите.

2. Распакуйте конфигурационные файлы, доступные в ваших заказах, в любой каталог.

3. Откройте конфигурационный файл ovpn в программе Viscosity.

4. Далее в верхнем меню рядом с часами кликаем на икноку Viscosity и в выпадающем меню программы выбираем Connect,

в диалоговом окне вводим имя пользователя и пароль (находятся в файле pass.txt в архиве в Ваших заказах).

5. Для проверки работы сервиса, можете обратитесь к странице https://whoer.net/ru. В отчете Вы можете увидеть текущий IP-адрес.
После окончания работы с VPN, кликните в меню Viscosity выберите Disconnect.

Настройка для OpenVPN Connect 3

1. Скачайте дистрибутив OpenVPN Connect 3 с официального сайта openvpn.net и установите его.

2. Скачайте конфигурационные файлы из личного кабинете и распакуйте их

3. Чтобы добавить конфигурационный файл в OpenVPN Connect просто переместите файл на приложение.

4. Отметье галочкой — Connect after import и нажмите Add

5. При появлении ошибки Connection error — Missing external certificate, нажмите Continue.

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

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

7. Впн подключение активируется, вы сможете управлять им в OpenVPN Connect.

Источник

External public key infrastructure (PKI)

Introduction

The Access Server external public key infrastructure (PKI) feature integrates Access Server with third-party tools for X509 PKI management, instead of using the built-in certificate management capabilities. When configured for external PKI usage, Access Server doesn’t manage client certificates directly; instead, the customer’s third-party PKI software generates and distributes client certificate/key pairs to client machines, and a server certificate/key pair to the OpenVPN server.This document describes how external PKI works with Access Server and provides an example setup using Access Server’s certool.

How external PKI mode works for Access Server

OpenVPN Access Server issues and manages its own certificates for the server and clients. This certificate infrastructure is the PKI and, by default, Access Server automatically manages and provisions the necessary certificates. Switching to external PKI mode involves handing off that management to a third-party tool. This changes how VPN client distribution occurs by using two channels rather than one:

1. Connection profile — distribution of OpenVPN Connect and a bundled, server-locked profile. The app and profile contain instructions on how to connect to the server and the software to make a connection. This can be done using the Client UI or by generating and distributing the client installer via the command line tools. Note: you must use the instructions to create server-locked profiles/installers for external PKI integration.
2. Certificate/key — the client certificate/key generated by a third-party tool. This third-party tool manages the external PKI solution. The tool generates the client certificates/keys and installs them on client machines using the host OS certificate/key store — iOS, macOS, Android Keychain, Windows certificate store, or Linux OpenSC. For a standard Access Server setup, not using external PKI, Access Server bundles the certificate/key with the connection profile. External PKI requires them to be separate

When operating in external PKI mode, Access Server only supports server-locked profiles, not user-locked profiles. For the VPN client, the server-locked profile must have a client certificate/key pair installed into the host OS keychain or certificate/key store in order to make a VPN tunnel connection. Some hardware devices or tokens contain a certificate inside that is registered with the certificate store using additional software when the token device/card is plugged in.

OpenVPN Connect does not require direct access to the private key, as it is capable of performing RSA operations on the key via the CSP (cryptographic service provider) API provided by the host OS Keychain. This allows the use of cryptographic tokens or smartcards with the private key, which makes it physically impossible for any software running on the client machine (even at root/Administrator level) to directly read the key.

Note: OpenVPN Support for external PKI systems with Access Server is limited. This is because much of the system is dependent on how the system administrator sets it up, that the external PKI mode disables many of the internal certificate management functions of Access Server, and that there is a third-party product involved and we have no control over that external system.

Configure external PKI for Access Server

When you use a third-party tool outside of Access Server, you must refer to the documentation for that software for specific directions. Here we outline the steps and provide an example using Access Server’s certool script. With certool, you can create your own, new PKI structure, as we do in these instructions.

At a high level, these are the steps for your configuration:

1. Create certificate/key pair with external PKI tool.
2. Modify as.conf to set Access Server in external PKI mode.
3. Create TLS_auth key.
4. Generate Diffie Hellman parameters.
5. Import the necessary certificate and key files.
6. Provide certificate/key pairs to VPN client and server.

When you configure your Access Server in production, follow these high-level steps using your third-party PKI tool. We provide our example, below, using Access Server’s certool script so the steps pertain to that tool.

Here’s how we configure external PKI using Access Server’s certool script.

Stop Access Server:

Edit as.conf for external PKI usage with a text editor such as nano:

Comment out certs_db:

Save and exit the file — with nano, hit ctrl+X, Y, then enter. After making this change, Access Server no longer uses the certificate database. Instead, an external system must handle this.

Initialize the external PKI files in the epki directory, including the CA cert/key:

Create a root cert for signing intermediate CAs:

Create the intermediate CA:

Create a certificate/key pair for the OpenVPN server:

Create a tls_auth key for the OpenVPN server:

Generate Diffie Hellman parameters for the OpenVPN server:

Load the newly generated files into the Access Server config database:

For Access Server 2.7 and greater, you must also generate your auth token and add the generated file:

Configure X509 explicit/extended key usage based on RFC3280 TLS Rules:

Configure use of the X509 “role” attribute for declaration of auto-login permission:

Beginning with Access Server version 2.9.0, generate the tls-crypt-v2 key. Skip this step for previous versions.

Start Access Server:

Note: When using an external PKI tool, make sure to designate all certificates generated by your PKI management tool as being explicitly client or server. This protects against a particular type of man-in-the-middle attack where a client certificate could be used to impersonate the server. There are two ways to do this:

1. X509 explicit/extended key usage based on RFC3280 TLS rules. Configure as follows: ./confdba -mk external_pki.remote_cert_usage -v eku
2. Netscape certificate type (deprecated). Configure as follows: ./confdba -mk external_pki.remote_cert_usage -v ns or for version 2.9.0 and later, ./confdba -mk external_pki.remote_cert_usage -v ns-cert

Configure a test client

To test our example, generate a test client, etest. Create the username and password for etest. To do this in the Admin Web UI, sign in, click User Management > User Permissions, then create the username and enter the password. Click Save and Update Running Server. This works for Local authentication. For PAM, LDAP, or RADIUS, create the test user in the appropriate location.

Generate a cert/key pair for etest — the key is encrypted with a password you enter at the prompt and certool generates the file epki/etest.p12 which contains the cert/key pair:

To test auto-login, generate an auto-login cert/key pair for etest:

Finally, generate a server-locked profile. The profile will be stored in client.ovpn:

Copy these three files to the client machine:

epki/etest.p12:	The userlogin cert/key pair for user etest
epki/etestauto.p12:	The autologin cert/key pair for user etest
client.ovpn:	The server-locked profile for the Access Server

In a production setting, the client cert/key pairs (the .p12 files) are distributed to clients using the external PKI tool. The client.ovpn is distributed in the same manner as existing server-locked profiles:

• Using OpenVPN Connect.
• Using a client software push capability — for example, on macOS, you can generate a pre-configured client installer, ‘DMG’, with the server-locked profile: ./sacli —itype dmg -o . GetGenericInstaller

To install the certificate/key pair:

• Mac:
  • Start the Keychain Access application.
  • Go to File > Import Items.
  • Import each .p12 file — to decrypt the file, you must enter the password from when you generated the file.
• Windows:
  • Go to Tools > Internet options.
  • Click the Content tab.
  • Click the Certificates button.
  • Click “Import” to import the .p12 files.

To import the server-locked profile and connect:

Note: If using an auto-login profile, omit the -u and -p parameters from the command above. For our example, the auto-login requires importing the epki/etestauto.p12 into the system certificate store.

During the connection process, the system certificate store may launch a dialog box. On Windows, this may start in a minimized state rather than popping up as it comes from the system certificate store and OpenVPN Connect doesn’t control how it displays. Click it to fully open and approve it in order to complete the connection.

VPN client support

OpenVPN Connect supports the macOS Keychain and the Windows certificate store as valid sources to fetch the client certificate.

When the user attempts to connect using a profile setup for external PKI, the client backend enumerates the user’s host OS certificate store and automatically selects the certificate/key pair issued by OpenVPN Access Server. If more than one certificate/key pair is eligible, the certificate with the latest expiration date is used.

Certificate naming conventions

Currently, the Access Server uses the following client certificate naming conventions:

1. The Common Name of the certificate must match the username of the connecting client.
2. Autologin certificates, which don’t require username/password authentication (only client certificate authentication), must be tagged to indicate that they hold this right. In the above example, note that the X509 role attribute is set to AUTOLOGIN. Then we modify Access Server’s configuration to indicate that autologin is enabled if the X509 «role» attribute contains the «AUTOLOGIN» substring: ./confdba -mk external_pki.autologin_x509_spec -v «role,,AUTOLOGIN» . If external_pki.autologin_x509_spec is omitted, all auto-login access is disabled. The external_pki.autologin_x509_spec string is formatted as follows: , , The flags parameter is reserved for future use and is currently unimplemented. So, for example, if external_pki.autologin_x509_spec is set to «role,,AUTOLOGIN», as the confdba command above does, then Access Server would only allow auto-login connections from client certificates where the «role» X509 attribute is present and the substring «AUTOLOGIN» exists within the «role» value.

Advanced features

Split CA, i.e. using a separate CA chain for client and server certificates

By default, one CA chain is assumed for both client and server certificates. To use a separate chain for each, first enable split CA mode:

Next, replace the following line (from above):

When using split CA mode, you don’t need to mark certificates as client or server. Therefore, settings for Netscape certificate type or X509 explicit/extended key usage based on RFC3280 TLS rules can be omitted.

Controlling CN/username requirement

By default, client logins must use a username that matches the Common Name on the client certificate. This requirement may be dropped by disabling the external_pki.cn_username_requirement boolean key:

Controlling which certificate store the client uses to fetch the client certificate

By default, the client fetches certificates from the «user» store. This corresponds to the user’s

/Library/Keychains/login.keychain store on Mac, and the «MY» store on Windows. On Mac, the store can be selected on the server using the user properties key «cert_store». Set it to «user», «system», or «both» to explicitly control the store that clients use:

user:	use /Library/Keychains/login.keychain
system:	use /Library/Keychains/System.keychain
both:	try system keychain, then fall back to user

For example, set the store to «both»:

Error Message

«‘Parameter \»external_pki.auth_token_key\» is missing from the configuration database. For more information, please visit the following URL: https://openvpn.net/static-links/documentation-external-pki’: util/cdict:286,util/cdict:258,util/cdict:522,util/cdict:555 (exceptions.KeyError)»

This error message occurs when upgrading an Access Server that’s configured for external public key infrastructure (ePKI) from a version lower than 2.7 to version 2.7 and higher. This is expected behavior because this configuration key was missing for versions prior to 2.7 and must be added after you upgrade. Note that you’ll also see “service failed to start or returned error status” in your log messages.

This error can be resolved by running these commands with root privileges:

Источник