- openssl ca -gencrl -crldays 15 -out crl.pem
-
-If you omit the `-crldays` option then the `default_crl_days` value (30 days)
-specified in `openssl.cnf` is used.
-
-If you prefer the CRL to be in binary DER format then this conversion
-can be achieved with
-
- openssl crl -in crl.pem -outform DER -out cert.crl
-
-The strongSwan PKI tool provides the `--signcrl` command to sign CRLs.
-
-The directory `/etc/ipsec.d/crls` contains all CRLs either in binary DER
-or in Base64 PEM format, irrespective of the file suffix the correct format
-will be determined.
-
-
-### Revoking a certificate ###
-
-A specific host certificate stored in the file `host.pem` is revoked with the
-command
-
- openssl ca -revoke host.pem
-
-Next the CRL file must be updated
-
- openssl ca -gencrl -crldays 60 -out crl.pem
-
-The content of the CRL file can be listed with the command
-
- openssl crl -in crl.pem -noout -text
-
-in the case of a Base64 CRL, or alternatively for a CRL in DER format
-
- openssl crl -inform DER -in cert.crl -noout -text
-
-Again the `--signcrl` command of the strongSwan PKI tool may also be used to
-create new CRLs containing additional certificates.
-
-
-## Configuring the connections - ipsec.conf ##
-
-### Configuring my side ###
-
-Usually the **local** side is the same for all connections. Therefore it makes
-sense to put the definitions characterizing the strongSwan security gateway into
-the `conn %default` section of the configuration file `/etc/ipsec.conf`. If we
-assume throughout this document that the strongSwan security gateway is **left**
-and the peer is **right** then we can write
-
- conn %default
- leftcert=moonCert.pem
- # load connection definitions automatically
- auto=add
-
-The X.509 certificate by which the strongSwan security gateway will authenticate
-itself by sending it in binary form to its peers as part of the Internet Key
-Exchange (IKE) is specified in the line
-
- leftcert=moonCert.pem
-
-The certificate can either be stored in Base64 PEM-format or in the binary
-DER-format. Irrespective of the file suffix the correct format will be
-determined. Therefore `leftcert=moonCert.der` or `leftcert=moonCert.cer`
-would also be valid alternatives.
-
-When using relative pathnames as in the examples above, the certificate files
-must be stored in in the directory `/etc/ipsec.d/certs`. In order to
-distinguish strongSwan's own certificates from locally stored trusted peer
-certificates (see below for details), they could also be stored in a
-subdirectory below `/etc/ipsec.d/certs` as e.g. in
-
- leftcert=mycerts/moonCert.pem
-
-Absolute pathnames are also possible as in
-
- leftcert=/usr/ssl/certs/moonCert.pem
-
-As an ID for the VPN gateway we recommend the use of a Fully Qualified Domain
-Name (FQDN) of the form
-
- conn rw
- right=%any
- leftid=moon.strongswan.org
-
-**Important**: When a FQDN identifier is used it must be explicitly included as
-a so called _subjectAltName_ of type _dnsName_ (`DNS:`) in the certificate
-indicated by `leftcert`. For details on how to generate certificates with
-_subjectAltNames_, please refer to the sections above.
-
-If you don't want to mess with _subjectAltNames_, you can use the certificate's
-Distinguished Name (DN) instead, which is an identifier of type _DER_ASN1_DN_
-and which can be written e.g. in the LDAP-type format
-
- conn rw
- right=%any
- leftid="C=CH, O=strongSwan, CN=moon.strongswan.org"
-
-Since the subject's DN is part of the certificate, the `leftid` does not have to
-be declared explicitly. Thus the entry
-
- conn rw
- right=%any
-
-automatically assumes the subject DN of `leftcert` to be the host ID.
-
-
-### Multiple certificates ###
-
-strongSwan supports multiple local host certificates and corresponding
-RSA private keys:
-
- conn rw1
- right=%any
- rightid=peer1.domain1
- leftcert=myCert1.pem
- # leftid is DN of myCert1
-
- conn rw2
- right=%any
- rightid=peer2.domain2
- leftcert=myCert2.pem
- # leftid is DN of myCert2
-
-When _peer1_ initiates a connection then strongSwan will send _myCert1_ and will
-sign with _myKey1_ defined in `/etc/ipsec.secrets` (see below) whereas
-_myCert2_ and _myKey2_ will be used in a connection setup started from _peer2_.
-
-
-### Configuring the peer side using CA certificates ###
-
-Now we can proceed to define our connections. In many applications we might
-have dozens of road warriors connecting to a central strongSwan security
-gateway. The following most simple statement:
-
- conn rw
- right=%any
-
-defines the general roadwarrior case. The line `right=%any` literally means
-that any IPsec peer is accepted, regardless of its current IP source address and
-its ID, as long as the peer presents a valid X.509 certificate signed by a CA
-the strongSwan security gateway puts explicit trust in. Additionally, the
-signature during IKE gives proof that the peer is in possession of the private
-key matching the public key contained in the transmitted certificate.
-
-The ID by which a peer is identifying itself during IKE can by any of the ID
-types _IPV[46]_ADDR_, _FQDN_, _RFC822_ADDR_ or _DER_ASN1_DN_. If one of the
-first three ID types is used, then the accompanying X.509 certificate of the
-peer must contain a matching _subjectAltName_ field of the type _ipAddress_
-(`IP:`), _dnsName_ (`DNS:`) or _rfc822Name_ (`email:`), respectively. With the
-fourth type, _DER_ASN1_DN_, the identifier must completely match the subject
-field of the peer's certificate. One of the two possible representations of a
-Distinguished Name (DN) is the LDAP-type format
-
- rightid="C=CH, O=strongSwan IPsec, CN=sun.strongswan.org"
-
-Additional whitespace can be added everywhere as desired since it will be
-automatically eliminated by the parser. An exception is the single whitespace
-between individual words, like e.g. in `strongSwan IPsec`, which is preserved.
-
-The Relative Distinguished Names (RDNs) can alternatively be separated by a
-slash `/` instead of a comma `,`
-
- rightid="/C=CH/O=strongSwan IPsec/CN=sun.strongswan.org"
-
-This is the representation extracted from the certificate by the OpenSSL
-`-subject` command line option
-
- openssl x509 -in sunCert.pem -noout -subject
-
-The following RDNs are supported by strongSwan
-
-| Name | Description |
-|--------------------|----------------------------------|
-| DC | Domain Component |
-| C | Country |
-| ST | State or province |
-| L | Locality or town |
-| O | Organization |
-| OU | Organizational Unit |
-| CN | Common Name |
-| ND | NameDistinguisher, used with CN |
-| N | Name |
-| G | Given name |
-| S | Surname |
-| I | Initials |
-| T | Personal title |
-| E | E-mail |
-| Email | E-mail |
-| emailAddress | E-mail |
-| SN | Serial number |
-| serialNumber | Serial number |
-| D | Description |
-| ID | X.500 Unique Identifier |
-| UID | User ID |
-| TCGID | [Siemens] Trust Center Global ID |
-| UN | Unstructured Name |
-| unstructuredName | Unstructured Name |
-| UA | Unstructured Address |
-| unstructuredAddress| Unstructured Address |
-| EN | Employee Number |
-| employeeNumber | Employee Number |
-| dnQualifier | DN Qualifier |
-
-With the roadwarrior connection definition listed above, an IPsec SA for
-the strongSwan security gateway `moon.strongswan.org` itself can be established.
-If the roadwarriors should be able to reach e.g. the two subnets `10.1.0.0/24`
-and `10.1.3.0/24` behind the security gateway then the following connection
-definitions will make this possible
-
- conn rw1
- right=%any
- leftsubnet=10.1.0.0/24
-
- conn rw3
- right=%any
- leftsubnet=10.1.3.0/24
-
-For IKEv2 connections this can even be simplified by using
-
- leftsubnet=10.1.0.0/24,10.1.3.0/24
-
-If not all peers in possession of a X.509 certificate signed by a specific
-certificate authority shall be given access to the Linux security gateway,
-then either a subset of them can be barred by listing the serial numbers of
-their certificates in a certificate revocation list (CRL) or as an alternative,
-access can be controlled by explicitly putting a roadwarrior entry for each
-eligible peer into `ipsec.conf`:
-
- conn sun
- right=%any
- rightid=sun.strongswan.org
-
- conn carol
- right=%any
- rightid=carol@strongswan.org
-
- conn dave
- right=%any
- rightid="C=CH, O=strongSwan, CN=dave@strongswan.org"
-
-When the IP address of a peer is known to be stable, it can be specified as
-well. This entry is mandatory when the strongSwan host wants to act as the
-initiator of an IPsec connection.
-
- conn sun
- right=192.168.0.2
- rightid=sun.strongswan.org
-
- conn carol
- right=192.168.0.100
- rightid=carol@strongswan.org
-
- conn dave
- right=192.168.0.200
- rightid="C=CH, O=strongSwan, CN=dave@strongswan.org"
-
- conn venus
- right=192.168.0.50
-
-In the last example the ID types _FQDN_, _RFC822_ADDR_, _DER_ASN1_DN_ and
-_IPV4_ADDR_, respectively, were used. Of course all connection definitions
-presented so far have included the lines in the `conn %defaults` section,
-comprising among other a `leftcert` entry.
-
-
-### Handling Virtual IPs and narrowing ###
-
-Often roadwarriors are behind NAT-boxes, which causes the inner IP source
-address of an IPsec tunnel to be different from the outer IP source address
-usually assigned dynamically by the ISP. Whereas the varying outer IP address
-can be handled by the `right=%any` construct, the inner IP address or subnet
-must always be declared in a connection definition. Therefore for the three
-roadwarriors _rw1_ to _rw3_ connecting to a strongSwan security gateway the
-following entries are required in `/etc/ipsec.conf`:
-
- conn rw1
- right=%any
- righsubnet=10.4.0.5/32
-
- conn rw2
- right=%any
- rightsubnet=10.4.0.47/32
-
- conn rw3
- right=%any
- rightsubnet=10.4.0.128/28
-
-Because the charon daemon uses narrowing (even for IKEv1) these three entries
-can be reduced to the single connection definition
-
- conn rw
- right=%any
- rightsubnet=10.4.0.0/24
-
-Any host will be accepted (of course after successful authentication based on
-the peer's X.509 certificate only) if it declares a client subnet lying totally
-within the boundaries defined by the subnet definition (in our example
-`10.4.0.0/24`).
-
-This strongSwan feature can also be helpful with VPN clients getting a
-dynamically assigned inner IP from a DHCP server located on the NAT router box.
-
-Since the private IP address of roadwarriors will often not be known they are
-usually assigned virtual IPs from a predefined pool. This also makes routing
-traffic back to the roadwarriors easier. For example, to assign each client an
-IP address from the `10.5.0.0/24` subnet `conn rw` can be defined as
-
- conn rw
- right=%any
- rightsourceip=10.5.0.0/24
-
-
-### Protocol and Port Selectors ###
-
-strongSwan offers the possibility to restrict the protocol and optionally the
-ports in an IPsec SA using the `rightprotoport` and `leftprotoport` parameters.
-For IKEv2 multiple such restrictions can also be configured in
-`leftsubnet` and `rightsubnet`.
-
-Some examples:
-
- conn icmp
- right=%any
- rightprotoport=icmp
- leftid=moon.strongswan.org
- leftprotoport=icmp
-
- conn http
- right=%any
- rightprotoport=6
- leftid=moon.strongswan.org
- leftprotoport=6/80
-
- conn l2tp
- right=%any
- # with port wildcard for interoperability with certain L2TP clients
- rightprotoport=17/%any
- leftid=moon.strongswan.org
- leftprotoport=17/1701
-
- conn dhcp
- right=%any
- rightprotoport=udp/bootpc
- leftid=moon.strongswan.org
- leftsubnet=0.0.0.0/0 #allows DHCP discovery broadcast
- leftprotoport=udp/bootps
-
-Protocols and ports can be designated either by their numerical values
-or by their acronyms defined in `/etc/services`.
-
-Based on the protocol and port selectors appropriate policies will be set
-up, so that only the specified payload types will pass through the IPsec
-tunnel.
-
-
-### IPsec policies based on wildcards ###
-
-In large VPN-based remote access networks there is often a requirement that
-access to the various parts of an internal network must be granted selectively,
-e.g. depending on the group membership of the remote access user. strongSwan
-makes this possible by applying wildcard filtering on the VPN user's
-distinguished name (_ID_DER_ASN1_DN_).
-
-Let's make a practical example:
-
-An organization has a sales department (_OU=Sales_) and a research group
-(_OU=Research_). In the company intranet there are separate subnets for Sales
-(`10.0.0.0/24`) and Research (`10.0.1.0/24`) but both groups share a common web
-server (`10.0.2.100`). The VPN clients use Virtual IP addresses that are either
-assigned statically or from a dynamic pool. The sales and research departments
-use IP addresses from separate address pools (`10.1.0.0/24`) and
-(`10.1.1.0/24`), respectively. An X.509 certificate is issued to each employee,
-containing in its subject distinguished name the country (_C=CH_), the company
-(_O=ACME_), the group membership (_OU=Sales_ or _OU=Research_) and the common
-name (e.g. _CN=Bart Simpson_).
-
-The IPsec policy defined above can now be enforced with the following three
-IPsec security associations:
-
- conn sales
- right=%any
- rightid="C=CH, O=ACME, OU=Sales, CN=*"
- rightsourceip=10.1.0.0/24 # Sales IP range
- leftsubnet=10.0.0.0/24 # Sales subnet
-
- conn research
- right=%any
- rightid="C=CH, O=ACME, OU=Research, CN=*"
- rightsourceip=10.1.1.0/24 # Research IP range
- leftsubnet=10.0.1.0/24 # Research subnet
-
- conn web
- right=%any
- rightid="C=CH, O=ACME, OU=*, CN=*"
- rightsubnet=10.1.0.0/23 # Remote access IP range
- leftsubnet=10.0.2.100/32 # Web server
- rightprotoport=tcp # TCP protocol only
- leftprotoport=tcp/http # TCP port 80 only
-
-The `*` character is used as a wildcard in relative distinguished names (RDNs).
-In order to match a wildcard template, the _ID_DER_ASN1_DN_ of a peer must
-contain the same number of RDNs (selected from the list given earlier) appearing
-in the exact order defined by the template.
-
- "C=CH, O=ACME, OU=Research, OU=Special Effects, CN=Bart Simpson"
-
-matches the templates
-
- "C=CH, O=ACME, OU=Research, OU=*, CN=*"
- "C=CH, O=ACME, OU=*, OU=Special Effects, CN=*"
- "C=CH, O=ACME, OU=*, OU=*, CN=*"
-
-but not the template
-
- "C=CH, O=ACME, OU=*, CN=*"
-
-which doesn't have the same number of RDNs.
-
-
-### IPsec policies based on CA certificates ###
-
-As an alternative to the wildcard based IPsec policies described above, access
-to specific client host and subnets can be controlled on the basis of the CA
-that issued the peer certificate
-
- conn sales
- right=%any
- rightca="C=CH, O=ACME, OU=Sales, CN=Sales CA"
- rightsourceip=10.1.0.0/24 # Sales IP range
- leftsubnet=10.0.0.0/24 # Sales subnet
-
- conn research
- right=%any
- rightca="C=CH, O=ACME, OU=Research, CN=Research CA"
- rightsourceip=10.1.1.0/24 # Research IP range
- leftsubnet=10.0.1.0/24 # Research subnet
-
- conn web
- right=%any
- rightca="C=CH, O=ACME, CN=ACME Root CA"
- rightsubnet=10.1.0.0/23 # Remote access IP range
- leftsubnet=10.0.2.100/32 # Web server
- rightprotoport=tcp # TCP protocol only
- leftprotoport=tcp/http # TCP port 80 only
-
-In the example above, the connection _sales_ can be used by peers
-presenting certificates issued by the Sales CA, only. In the same way,
-the use of the connection _research_ is restricted to owners of certificates
-issued by the Research CA. The connection _web_ is open to both "Sales" and
-"Research" peers because the required _ACME Root CA_ is the issuer of the
-Research and Sales intermediate CAs. If no `rightca` parameter is present
-then any valid certificate issued by one of the trusted CAs in
-`/etc/ipsec.d/cacerts` can be used by the peer.
-
-The `leftca` parameter usually doesn't have to be set explicitly because
-by default it is set to the issuer field of the certificate loaded via
-`leftcert`. The statement
-
- rightca=%same
-
-sets the CA requested from the peer to the CA used by the left side itself
-as e.g. in
-
- conn sales
- right=%any
- rightca=%same
- leftcert=mySalesCert.pem
-
-
-## Configuring certificates and CRLs ##
-
-
-### Installing the CA certificates ###
-
-X.509 certificates received by strongSwan during the IKE protocol are
-automatically authenticated by going up the trust chain until a self-signed
-root CA certificate is reached. Usually host certificates are directly signed
-by a root CA, but strongSwan also supports multi-level hierarchies with
-intermediate CAs in between. All CA certificates belonging to a trust chain
-must be copied in either binary DER or Base64 PEM format into the directory
-
- /etc/ipsec.d/cacerts/
-
-
-### Installing optional certificate revocation lists (CRLs) ###
projects / strongswan.git / blobdiff