package: openssl-LibreSSL

title: x509v3-LibreSSL.cnf(5)

text:
# x509v3-LibreSSL.cnf(5)

## NAME
x509v3.cnf — X.509 V3 certificate extension configuration format

## DESCRIPTION
Several of the OpenSSL utilities can add extensions to a certificate or certificate request based on the contents of a configuration file. The file format is based on the openssl.cnf(5) format.

Typically the application will contain an option to point to an extension section. Each line of the extension section takes the form:

extension_name=[critical,] extension_options

If critical is present, then the extension will be critical.

The format of extension_options depends on the value of extension_name.

There are four main types of extension: string extensions, multi-valued extensions, raw extensions, and arbitrary extensions.

String extensions simply have a string which contains either the value itself or how it is obtained. For example:

nsComment="This is a Comment"

Multi-valued extensions have a short form and a long form. The short form is a list of names and values:

basicConstraints=critical,CA:true,pathlen:1

The long form allows the values to be placed in a separate section:

```
basicConstraints=critical,@bs_section

[bs_section]
CA=true
pathlen=1
```

Both forms are equivalent.

The syntax of raw extensions is governed by the extension code: it can for example contain data in multiple sections. The correct syntax to use is defined by the extension code itself: check out the certificate policies extension for an example.

If an extension type is unsupported, then the arbitrary extension syntax must be used; see the ARBITRARY EXTENSIONS section for more details.

## STANDARD EXTENSIONS
The following sections describe each supported extension in detail.

### Basic constraints
This is a multi-valued extension which indicates whether a certificate is a CA certificate. The first (mandatory) name is CA followed by TRUE or FALSE. If CA is TRUE, then an optional pathlen name followed by a non-negative value can be included. For example:

```
basicConstraints=CA:TRUE
basicConstraints=CA:FALSE
basicConstraints=critical,CA:TRUE, pathlen:0
```

A CA certificate must include the basicConstraints value with the CA field set to TRUE. An end user certificate must either set CA to FALSE or exclude the extension entirely. Some software may require the inclusion of basicConstraints with CA set to FALSE for end entity certificates.

The pathlen parameter indicates the maximum number of CAs that can appear below this one in a chain. So if you have a CA with a pathlen of zero, it can only be used to sign end user certificates and not further CAs.

### Key usage
Key usage is a multi-valued extension consisting of a list of names of the permitted key usages.

The supported names are: digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, and decipherOnly. Examples:

```
keyUsage=digitalSignature, nonRepudiation
keyUsage=critical, keyCertSign
```

### Extended key usage
This extension consists of a list of purposes for which the certificate public key can be used.

These can either be object short names or the dotted numerical form of OIDs. While any OID can be used, only certain values make sense. In particular the following PKIX, NS and MS values are meaningful:

value

meaning

serverAuth

TLS server authentication

clientAuth

TLS client authentication

codeSigning

code signing

emailProtection

E-mail protection (S/MIME)

timeStamping

trusted timestamping

OCSPSigning

OCSP signing

ipsecIKE

IPsec internet key exchange

msCodeInd

Microsoft individual code signing (authenticode)

msCodeCom

Microsoft commercial code signing (authenticode)

msCTLSign

Microsoft trust list signing

msEFS

Microsoft encrypted file system

Examples:

```
extendedKeyUsage=critical,codeSigning,1.2.3.4
extendedKeyUsage=serverAuth,clientAuth
```

### Subject key identifier
This is really a string extension and can take two possible values. Either the word hash which will automatically follow the guidelines in RFC 3280 or a hex string giving the extension value to include. The use of the hex string is strongly discouraged. Example:

subjectKeyIdentifier=hash

### Authority key identifier
The authority key identifier extension permits two options, keyid and issuer: both can take the optional value always.

If the keyid option is present, an attempt is made to copy the subject key identifier from the parent certificate. If the value always is present, then an error is returned if the option fails.

The issuer option copies the issuer and serial number from the issuer certificate. This will only be done if the keyid option fails or is not included unless the always flag will always include the value. Example:

authorityKeyIdentifier=keyid,issuer

### Subject alternative name
The subject alternative name extension allows various literal values to be included in the configuration file. These include email (an email address), URI (a uniform resource indicator), DNS (a DNS domain name), RID (a registered ID: OBJECT IDENTIFIER), IP (an IP address), dirName (a distinguished name), and otherName.

The email option can include a special copy value. This will automatically include any email addresses contained in the certificate subject name in the extension.

The IP address used in the IP options can be in either IPv4 or IPv6 format.

The value of dirName should point to a section containing the distinguished name to use as a set of name value pairs. Multi values AVAs can be formed by prefacing the name with a ‘+’ character.

otherName can include arbitrary data associated with an OID: the value should be the OID followed by a semicolon and the content in standard ASN1_generate_nconf(3) format. Examples:

```
subjectAltName=email:copy,email:my@other.address,URI:http://my.url.here/
subjectAltName=IP:192.168.7.1
subjectAltName=IP:13::17
subjectAltName=email:my@other.address,RID:1.2.3.4
subjectAltName=otherName:1.2.3.4;UTF8:some other identifier

subjectAltName=dirName:dir_sect

[dir_sect]
C=UK
O=My Organization
OU=My Unit
CN=My Name
```

### Issuer alternative name
The issuer alternative name option supports all the literal options of subject alternative name. It does not support the email:copy option because that would not make sense. It does support an additional issuer:copy option that will copy all the subject alternative name values from the issuer certificate (if possible). Example:

issuerAltName = issuer:copy

### Authority info access
The authority information access extension gives details about how to access certain information relating to the CA. Its syntax is accessOID; location where location has the same syntax as subject alternative name (except that email:copy is not supported). accessOID can be any valid OID but only certain values are meaningful, for example OCSP and caIssuers. Example:

```
authorityInfoAccess = OCSP;URI:http://ocsp.my.host/
authorityInfoAccess = caIssuers;URI:http://my.ca/ca.html
```

### CRL distribution points
This is a multi-valued extension whose options can be either in name:value pair form using the same form as subject alternative name or a single value representing a section name containing all the distribution point fields.

For a name:value pair a new DistributionPoint with the fullName field set to the given value, both the cRLissuer and reasons fields are omitted in this case.

In the single option case, the section indicated contains values for each field. In this section:

If the name is fullname, the value field should contain the full name of the distribution point in the same format as subject alternative name.

If the name is relativename, then the value field should contain a section name whose contents represent a DN fragment to be placed in this field.

The name CRLIssuer, if present, should contain a value for this field in subject alternative name format.

If the name is reasons, the value field should consist of a comma separated field containing the reasons. Valid reasons are: keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn, and AACompromise.

Simple examples:

```
crlDistributionPoints=URI:http://myhost.com/myca.crl
crlDistributionPoints=URI:http://my.com/my.crl,URI:http://oth.com/my.crl
```

Full distribution point example:

```
crlDistributionPoints=crldp1_section

[crldp1_section]
fullname=URI:http://myhost.com/myca.crl
CRLissuer=dirName:issuer_sect
reasons=keyCompromise, CACompromise

[issuer_sect]
C=UK
O=Organisation
CN=Some Name
```

### Issuing distribution point
This extension should only appear in CRLs. It is a multi-valued extension whose syntax is similar to the "section" pointed to by the CRL distribution points extension with a few differences.

The names reasons and CRLissuer are not recognized.

The name onlysomereasons is accepted, which sets this field. The value is in the same format as the CRL distribution point reasons field.

The names onlyuser, onlyCA, onlyAA, and indirectCRL are also accepted. The values should be a boolean values (TRUE or FALSE) to indicate the value of the corresponding field. Example:

```
issuingDistributionPoint=critical, @idp_section

[idp_section]
fullname=URI:http://myhost.com/myca.crl
indirectCRL=TRUE
onlysomereasons=keyCompromise, CACompromise

[issuer_sect]
C=UK
O=Organisation
CN=Some Name
```

### Certificate policies
This is a raw extension. All the fields of this extension can be set by using the appropriate syntax.

If you follow the PKIX recommendations and just use one OID, then you just include the value of that OID. Multiple OIDs can be set separated by commas, for example:

certificatePolicies= 1.2.4.5, 1.1.3.4

If you wish to include qualifiers, then the policy OID and qualifiers need to be specified in a separate section: this is done by using the @section syntax instead of a literal OID value.

The section referred to must include the policy OID using the name policyIdentifier. CPSuri qualifiers can be included using the syntax:

CPS.nnn=value

userNotice qualifiers can be set using the syntax:

userNotice.nnn=@notice

The value of the userNotice qualifier is specified in the relevant section. This section can include explicitText, organization, and noticeNumbers options. explicitText and organization are text strings, and noticeNumbers is a comma separated list of numbers. The organization and noticeNumbers options (if included) must both be present. If you use the userNotice option with IE5 then you need the ia5org option at the top level to modify the encoding: otherwise it will not be interpreted properly. Example:

```
certificatePolicies=ia5org,1.2.3.4,1.5.6.7.8,@polsect

[polsect]
policyIdentifier = 1.3.5.8
CPS.1="http://my.host.name/"
CPS.2="http://my.your.name/"
userNotice.1=@notice

[notice]
explicitText="Explicit Text Here"
organization="Organisation Name"
noticeNumbers=1,2,3,4
```

The ia5org option changes the type of the organization field. In RFC 2459, it can only be of type DisplayText. In RFC 3280, IA5String is also permissible. Some software (for example some versions of MSIE) may require ia5org.

### Policy constraints
This is a multi-valued extension which consists of the names requireExplicitPolicy or inhibitPolicyMapping and a non-negative integer value. At least one component must be present. Example:

policyConstraints = requireExplicitPolicy:3

### Inhibit any policy
This is a string extension whose value must be a non-negative integer. Example:

inhibitAnyPolicy = 2

### Name constraints
The name constraints extension is a multi-valued extension. The name should begin with the word permitted or excluded, followed by a semicolon. The rest of the name and the value follows the syntax of subjectAltName except email:copy is not supported and the IP form should consist of an IP addresses and subnet mask separated by a slash. Examples:

```
nameConstraints=permitted;IP:192.168.0.0/255.255.0.0
nameConstraints=permitted;email:.somedomain.com
nameConstraints=excluded;email:.com
```

### OCSP no check
The OCSP no check extension is a string extension, but its value is ignored. Example:

noCheck = ignored

### TLS Feature (aka must staple)
This is a multi-valued extension consisting of a list of TLS extension identifiers. Each identifier may be a number in the range from 0 to 65535 or a supported name. When a TLS client sends a listed extension, the TLS server is expected to include that extension in its reply.

The supported names are: status_request and status_request_v2. Example:

tlsfeature = status_request

## DEPRECATED EXTENSIONS
The following extensions are non-standard, Netscape specific and largely obsolete. Their use in new applications is discouraged.

### Netscape string extensions
Netscape comment (nsComment) is a string extension containing a comment which will be displayed when the certificate is viewed in some browsers. Example:

nsComment = Some Random Comment

Other supported extensions in this category are: nsBaseUrl, nsRevocationUrl, nsCaRevocationUrl, nsRenewalUrl, nsCaPolicyUrl, and nsSslServerName.

### Netscape certificate type
This is a multi-valued extensions which consists of a list of flags to be included. It was used to indicate the purposes for which a certificate could be used. The basicConstraints, keyUsage, and extended key usage extensions are now used instead.

Acceptable values for nsCertType are: client, server, email, objsign, reserved, sslCA, emailCA, objCA.

## ARBITRARY EXTENSIONS
If an extension is not supported by the OpenSSL code, then it must be encoded using the arbitrary extension format. It is also possible to use the arbitrary format for supported extensions. Extreme care should be taken to ensure that the data is formatted correctly for the given extension type.

There are two ways to encode arbitrary extensions.

The first way is to use the word ASN1 followed by the extension content using the same syntax as ASN1_generate_nconf(3). For example:

```
1.2.3.4=critical,ASN1:UTF8String:Some random data
1.2.3.4=ASN1:SEQUENCE:seq_sect

[seq_sect]
field1 = UTF8:field1
field2 = UTF8:field2
```

It is also possible to use the word DER to include the raw encoded data in any extension.

```
1.2.3.4=critical,DER:01:02:03:04
1.2.3.4=DER:01020304
```

The value following DER is a hex dump of the DER encoding of the extension. Any extension can be placed in this form to override the default behaviour. For example:

basicConstraints=critical,DER:00:01:02:03

## FILES
/etc/libressl/x509v3.cnf

standard configuration file

## SEE ALSO
openssl-LibreSSL(1), ASN1_generate_nconf(3), OPENSSL_config(3), openssl.cnf(5)

## HISTORY
X509v3 extension code was first added to OpenSSL 0.9.2.

## CAVEATS
There is no guarantee that a specific implementation will process a given extension. It may therefore sometimes be possible to use certificates for purposes prohibited by their extensions because a specific application does not recognize or honour the values of the relevant extensions.

The DER and ASN1 options should be used with caution. It is possible to create totally invalid extensions if they are not used carefully.

If an extension is multi-value and a field value must contain a comma, the long form must be used. Otherwise the comma would be misinterpreted as a field separator. For example,

subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar

will produce an error, but the following form is valid:

```
subjectAltName=@subject_alt_section

[subject_alt_section]
subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar
```

Due to the behaviour of the OpenSSL CONF library, the same field name can only occur once in a section. That means that

```
subjectAltName=@alt_section

[alt_section]
email=steve@here
email=steve@there
```

will only use the last value. This can be worked around by using the form:

```
[alt_section]
email.1=steve@here
email.2=steve@there
```


openvpn-examples

package: openvpn

title: openvpn-examples(5)

summary: Secure IP tunnel daemon

text:
# openvpn-examples(5)

## NAME
openvpn examples - Secure IP tunnel daemon

## INTRODUCTION
This man page gives a few simple examples to create OpenVPN setups and configuration files.

## SMALL OPENVPN SETUP WITH PEER-FINGERPRINT
This section consists of instructions how to build a small OpenVPN setup with the peer-fingerprint option. This has the advantage of being easy to setup and should be suitable for most small lab and home setups without the need for a PKI. For bigger scale setup setting up a PKI (e.g. via easy-rsa) is still recommended.

Both server and client configuration can be further modified to customise the setup.

### Server setup
1.

Install openvpn Compile from source-code (see INSTALL file) or install via a distribution (apt/yum/ports) or via installer (Windows).

2.

Generate a self-signed certificate for the server:

```
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 -keyout server.key -out server.crt -nodes -sha256 -days 3650 -subj '/CN=server'
```

3.

Generate SHA256 fingerprint of the server certificate Use the OpenSSL command line utility to view the fingerprint of just created certificate:

```
openssl x509 -fingerprint -sha256 -in server.crt -noout
```

This outputs something similar to:

```
SHA256 Fingerprint=00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff
```

4.

Write a server configuration (server.conf):

```
# The server certificate we created in step 1
cert server.crt
key server.key
dh none
dev tun
# Listen on IPv6+IPv4 simultaneously
proto udp6
# The ip address the server will distribute
server 10.8.0.0 255.255.255.0
server-ipv6 fd00:6f76:706e::/64
# A tun-mtu of 1400 avoids problems of too big packets after VPN encapsulation
tun-mtu 1400
# The fingerprints of your clients. After adding/removing one here restart the
# server
<peer-fingerprint>
</peer-fingerprint>
# Notify clients when you restart the server to reconnect quickly
explicit-exit-notify 1
# Ping every 60s, restart if no data received for 5 minutes
keepalive 60 300
# Uncomment the line below if you want to have persistent IP addresses
# ifconfig-pool-persist  /etc/openvpn/server/ipp.txt
# Uncomment the line below to push a DNS server to clients
# push "dhcp-option DNS 1.1.1.1"
```

5.

Add at least one client as described in the client section.

6.

Start the server.

•

On systemd based distributions move server.crt, server.key and server.conf to /etc/openvpn/server and start it via systemctl

```
sudo mv server.conf server.key server.crt /etc/openvpn/server
sudo systemctl start openvpn-server@server
```

### Adding a client
1.

Install OpenVPN

2.

Generate a self-signed certificate for the client. In this example the client name is alice. Each client should have a unique name. Replace alice with a different name for each client.

```
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 -keyout - -nodes -sha256 -days 3650 -subj '/CN=alice'
```

This generate a certificate and a key for the client. The output of the command will look something like this:

```
-----BEGIN PRIVATE KEY-----
[base64 content]
-----END PRIVATE KEY-----
-----
-----BEGIN CERTIFICATE-----
[base 64 content]
-----END CERTIFICATE-----
```

3.

Create a new client configuration file. In this example we will name the file alice.ovpn:

```
# The name of your server to connect to
remote yourserver.example.net
client
# use a random source port instead the fixed 1194
nobind
# Uncomment the following line if you want to route
# all traffic via the VPN
# redirect-gateway def1 ipv6
# To set a DNS server
# dhcp-option DNS 192.168.234.1
<key>
-----BEGIN PRIVATE KEY-----
[Insert here the key created in step 2]
-----END PRIVATE KEY-----
</key>
<cert>
-----BEGIN CERTIFICATE-----
[Insert here the certificate created in step 2]
-----END CERTIFICATE-----
</cert>
# This is the fingerprint of the server that we trust. We generated this fingerprint
# in step 2 of the server setup
peer-fingerprint 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff
# The tun-mtu of the client should match the server MTU
tun-mtu 1400
dev tun
```

4.

Generate the fingerprint of the client certificate. For that we will let OpenSSL read the client configuration file as the x509 command will ignore anything that is not between the begin and end markers of the certificate:

```
openssl x509 -fingerprint -sha256 -noout -in alice.ovpn
```

This will again output something like

```
SHA256 Fingerprint=ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00:ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00
```

5.

Edit the server.conf configuration file and add this new client fingerprint as additional line between <peer-fingerprint> and </peer-fingerprint> After adding two clients the part of configuration would look like this:

```
<peer-fingerprint>
ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00:ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00
99:88:77:66:55:44:33:22:11:00:ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00:88:77:66:55:44:33
</peer-fingerprint>
```

6.

(optional) if the client is an older client that does not support the peer-fingerprint (e.g. OpenVPN 2.5 and older, OpenVPN Connect 3.3 and older), the client config alice.ovpn can be modified to still work with these clients. Remove the line starting with peer-fingerprint. Then add a new <ca> section at the end of the configuration file with the contents of the server.crt created in step 2 of the server setup. The end of alice.ovpn file should like:

```
[...]  # Beginning of the file skipped
</cert>
# The tun-mtu of the client should match the server MTU
tun-mtu 1400
dev tun
<ca>
[contents of the server.crt]
</ca>
```

Note that we put the <ca> section after the <cert> section to make the fingerprint generation from step 4 still work since it will only use the first certificate it finds.

7.

Import the file into the OpenVPN client or just use the openvpn alice.ovpn to start the VPN.

## EXAMPLES
Prior to running these examples, you should have OpenVPN installed on two machines with network connectivity between them. If you have not yet installed OpenVPN, consult the INSTALL file included in the OpenVPN distribution.

### Firewall Setup:
If firewalls exist between the two machines, they should be set to forward the port OpenVPN is configured to use, in both directions. The default for OpenVPN is 1194/udp. If you do not have control over the firewalls between the two machines, you may still be able to use OpenVPN by adding --ping 15 to each of the openvpn commands used below in the examples (this will cause each peer to send out a UDP ping to its remote peer once every 15 seconds which will cause many stateful firewalls to forward packets in both directions without an explicit firewall rule).

Please see your operating system guides for how to configure the firewall on your systems.

### VPN Address Setup:
For purposes of our example, our two machines will be called bob.example.com and alice.example.com. If you are constructing a VPN over the internet, then replace bob.example.com and alice.example.com with the internet hostname or IP address that each machine will use to contact the other over the internet.

Now we will choose the tunnel endpoints. Tunnel endpoints are private IP addresses that only have meaning in the context of the VPN. Each machine will use the tunnel endpoint of the other machine to access it over the VPN. In our example, the tunnel endpoint for bob.example.com will be 10.4.0.1 and for alice.example.com, 10.4.0.2.

Once the VPN is established, you have essentially created a secure alternate path between the two hosts which is addressed by using the tunnel endpoints. You can control which network traffic passes between the hosts (a) over the VPN or (b) independently of the VPN, by choosing whether to use (a) the VPN endpoint address or (b) the public internet address, to access the remote host. For example if you are on bob.example.com and you wish to connect to alice.example.com via ssh without using the VPN (since ssh has its own built-in security) you would use the command ssh alice.example.com. However in the same scenario, you could also use the command telnet 10.4.0.2 to create a telnet session with alice.example.com over the VPN, that would use the VPN to secure the session rather than ssh.

You can use any address you wish for the tunnel endpoints but make sure that they are private addresses (such as those that begin with 10 or 192.168) and that they are not part of any existing subnet on the networks of either peer, unless you are bridging. If you use an address that is part of your local subnet for either of the tunnel endpoints, you will get a weird feedback loop.

### Example 1: A simple tunnel without security (not recommended)
On bob:

```
openvpn --remote alice.example.com --dev tun1 \

         --ifconfig 10.4.0.1 10.4.0.2 --verb 9
```

On alice:

```
openvpn --remote bob.example.com --dev tun1 \

         --ifconfig 10.4.0.2 10.4.0.1 --verb 9
```

Now verify the tunnel is working by pinging across the tunnel.

On bob:

```
ping 10.4.0.2
```

On alice:

```
ping 10.4.0.1
```

The --verb 9 option will produce verbose output, similar to the tcpdump(8) program. Omit the --verb 9 option to have OpenVPN run quietly.

### Example 2: A tunnel with self-signed certificates and fingerprint
First build a self-signed certificate on bob and display its fingerprint.

```
openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout bob.pem -out bob.pem -nodes -sha256 -days 3650 -subj '/CN=bob'
openssl x509 -noout -sha256 -fingerprint -in bob.pem
```

and the same on alice:

```
openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout alice.pem -out alice.pem -nodes -sha256 -days 3650 -subj '/CN=alice'
openssl x509 -noout -sha256 -fingerprint -in alice.pem
```

These commands will build a text file called bob.pem or alice.pem (in ascii format) that contain both self-signed certificate and key and show the fingerprint of the certificates. Transfer the fingerprints over a secure medium such as by using the scp(1) or ssh(1) program.

On bob:

```
openvpn --ifconfig 10.4.0.1 10.4.0.2 --tls-server --dev tun --dh none \

        --cert bob.pem --key bob.pem --cipher AES-256-GCM \

        --peer-fingerprint "$fingerprint_of_alices_cert"
```

On alice:

```
openvpn --remote bob.example.com --tls-client --dev tun1   \

        --ifconfig 10.4.0.2 10.4.0.1 --cipher AES-256-GCM  \

        --cert alice.pem --key alice.pem                   \

        --peer-fingerprint "$fingerprint_of_bobs_cert"
```

Now verify the tunnel is working by pinging across the tunnel.

On bob:

```
ping 10.4.0.2
```

On alice:

```
ping 10.4.0.1
```

Note: This example use a elliptic curve (secp384), which allows --dh to be set to none.

### Example 3: A tunnel with full PKI and TLS-based security
For this test, we will designate bob as the TLS client and alice as the TLS server.

Note:

The client or server designation only has meaning for the TLS subsystem. It has no bearing on OpenVPN's peer-to-peer, UDP-based communication model.*

First, build a separate certificate/key pair for both bob and alice (see above where --cert is discussed for more info). Then construct Diffie Hellman parameters (see above where --dh is discussed for more info). You can also use the included test files client.crt, client.key, server.crt, server.key and ca.crt. The .crt files are certificates/public-keys, the .key files are private keys, and ca.crt is a certification authority who has signed both client.crt and server.crt. For Diffie Hellman parameters you can use the included file dh2048.pem.

WARNING:

All client, server, and certificate authority certificates and keys included in the OpenVPN distribution are totally insecure and should be used for testing only.

On bob:

```
openvpn --remote alice.example.com --dev tun1    \

        --ifconfig 10.4.0.1 10.4.0.2             \

        --tls-client --ca ca.crt                 \

        --cert client.crt --key client.key       \

        --reneg-sec 60 --verb 5
```

On alice:

```
openvpn --remote bob.example.com --dev tun1      \

        --ifconfig 10.4.0.2 10.4.0.1             \

        --tls-server --dh dh1024.pem --ca ca.crt \

        --cert server.crt --key server.key       \

        --reneg-sec 60 --verb 5
```

Now verify the tunnel is working by pinging across the tunnel.

On bob:

```
ping 10.4.0.2
```

On alice:

```
ping 10.4.0.1
```

Notice the --reneg-sec 60 option we used above. That tells OpenVPN to renegotiate the data channel keys every minute. Since we used --verb 5 above, you will see status information on each new key negotiation.

For production operations, a key renegotiation interval of 60 seconds is probably too frequent. Omit the --reneg-sec 60 option to use OpenVPN's default key renegotiation interval of one hour.

### Routing:
Assuming you can ping across the tunnel, the next step is to route a real subnet over the secure tunnel. Suppose that bob and alice have two network interfaces each, one connected to the internet, and the other to a private network. Our goal is to securely connect both private networks. We will assume that bob's private subnet is 10.0.0.0/24 and alice's is 10.0.1.0/24.

First, ensure that IP forwarding is enabled on both peers. On Linux, enable routing:

```
echo 1 > /proc/sys/net/ipv4/ip_forward
```

This setting is not persistent. Please see your operating systems documentation how to properly configure IP forwarding, which is also persistent through system boots.

If your system is configured with a firewall. Please see your operating systems guide on how to configure the firewall. You typically want to allow traffic coming from and going to the tun/tap adapter OpenVPN is configured to use.

On bob:

```
route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.4.0.2
```

On alice:

```
route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.4.0.1
```

Now any machine on the 10.0.0.0/24 subnet can access any machine on the 10.0.1.0/24 subnet over the secure tunnel (or vice versa).

In a production environment, you could put the route command(s) in a script and execute with the --up option.