ims-volte-vowifi
/
strongswan
9
0
Fork 0
Code Pull Requests Releases Activity

README: Fix indentation

This commit is contained in:
Tobias Brunner 2018-07-06 12:09:32 +02:00
parent 39bc437771
commit aad9021fd3
2 changed files with 170 additions and 170 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
README.md
View File

@ -57,7 +57,7 @@ Configuration on gateway _moon_:
local_ts = 10.1.0.0/16 local_ts = 10.1.0.0/16
remote_ts = 10.2.0.0/16 remote_ts = 10.2.0.0/16
start_action = trap start_action = trap
} }
} }
} }
} }
@ -87,7 +87,7 @@ Configuration on gateway _sun_:
local_ts = 10.2.0.0/16 local_ts = 10.2.0.0/16
remote_ts = 10.1.0.0/16 remote_ts = 10.1.0.0/16
start_action = trap start_action = trap
} }
} }
} }
} }
@ -116,7 +116,7 @@ connections we will use the default IPsec tunnel mode.
| 192.168.0.1 | === | 192.168.0.2 | | 192.168.0.1 | === | 192.168.0.2 |
moon sun moon sun
Configuration on host _moon_: Configuration on host _moon_:
/etc/swanctl/x509ca/strongswanCert.pem /etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem /etc/swanctl/x509/moonCert.pem
@ -167,7 +167,7 @@ Configuration on host _sun_:
children { children {
host-host { host-host {
start_action = trap start_action = trap
} }
} }
} }
} }
@ -215,7 +215,7 @@ Configuration on roadwarrior _carol_:
/etc/swanctl/swanctl.conf: /etc/swanctl/swanctl.conf:
connections { connections {
home { home {
remote_addrs = moon.strongswan.org remote_addrs = moon.strongswan.org
@ -315,7 +315,7 @@ Configuration on roadwarrior _carol_:
/etc/swanctl/swanctl.conf: /etc/swanctl/swanctl.conf:
connections { connections {
home { home {
remote_addrs = moon.strongswan.org remote_addrs = moon.strongswan.org
vips = 0.0.0.0 vips = 0.0.0.0
@ -378,16 +378,16 @@ Configuration on gateway _moon_:
The `swanctl.conf` file additionally contains a `secrets` section defining all The `swanctl.conf` file additionally contains a `secrets` section defining all
client credentials client credentials
secrets { secrets {
eap-carol { eap-carol {
id = carol@strongswan.org id = carol@strongswan.org
secret = Ar3etTnp secret = Ar3etTnp
} }
eap-dave { eap-dave {
id = dave@strongswan.org id = dave@strongswan.org
secret = W7R0g3do secret = W7R0g3do
} }
} }
Configuration on roadwarrior _carol_: Configuration on roadwarrior _carol_:
@ -395,7 +395,7 @@ Configuration on roadwarrior _carol_:
/etc/swanctl/swanctl.conf: /etc/swanctl/swanctl.conf:
connections { connections {
home { home {
remote_addrs = moon.strongswan.org remote_addrs = moon.strongswan.org
@ -416,12 +416,12 @@ Configuration on roadwarrior _carol_:
} }
} }
secrets { secrets {
eap-carol { eap-carol {
id = carol@strongswan.org id = carol@strongswan.org
secret = Ar3etTnp secret = Ar3etTnp
} }
} }
### Roadwarrior Case with EAP Identity ### ### Roadwarrior Case with EAP Identity ###
@ -461,16 +461,16 @@ Configuration on gateway _moon_:
} }
} }
secrets { secrets {
eap-carol { eap-carol {
id = carol id = carol
secret = Ar3etTnp secret = Ar3etTnp
} }
eap-dave { eap-dave {
id = dave id = dave
secret = W7R0g3do secret = W7R0g3do
} }
} }
Configuration on roadwarrior _carol_: Configuration on roadwarrior _carol_:
@ -478,7 +478,7 @@ Configuration on roadwarrior _carol_:
/etc/swanctl/swanctl.conf: /etc/swanctl/swanctl.conf:
connections { connections {
home { home {
remote_addrs = moon.strongswan.org remote_addrs = moon.strongswan.org
@ -499,12 +499,12 @@ Configuration on roadwarrior _carol_:
} }
} }
secrets { secrets {
eap-carol { eap-carol {
id = carol id = carol
secret = Ar3etTnp secret = Ar3etTnp
} }
} }
## Generating Certificates and CRLs ## ## Generating Certificates and CRLs ##

260
README_LEGACY.md
View File

@ -252,7 +252,7 @@ correctly.
If you prefer the CA certificate to be in binary DER format then the following If you prefer the CA certificate to be in binary DER format then the following
command achieves this transformation: command achieves this transformation:
openssl x509 -in strongswanCert.pem -outform DER -out strongswanCert.der openssl x509 -in strongswanCert.pem -outform DER -out strongswanCert.der
The statements The statements
@ -275,8 +275,8 @@ the correct format will be determined.
The OpenSSL statement The OpenSSL statement
openssl req -newkey rsa:2048 -keyout hostKey.pem \ openssl req -newkey rsa:2048 -keyout hostKey.pem \
-out hostReq.pem -out hostReq.pem
generates a 2048 bit RSA private key `hostKey.pem` and a certificate request generates a 2048 bit RSA private key `hostKey.pem` and a certificate request
`hostReq.pem` which has to be signed by the CA. `hostReq.pem` which has to be signed by the CA.
@ -285,16 +285,16 @@ If you want to add a _subjectAltName_ field to the host certificate you must
edit the OpenSSL configuration file `openssl.cnf` and add the following line in edit the OpenSSL configuration file `openssl.cnf` and add the following line in
the `[ usr_cert ]` section: the `[ usr_cert ]` section:
subjectAltName=DNS:moon.strongswan.org subjectAltName=DNS:moon.strongswan.org
if you want to identify the host by its Fully Qualified Domain Name (FQDN), or if you want to identify the host by its Fully Qualified Domain Name (FQDN), or
subjectAltName=IP:192.168.0.1 subjectAltName=IP:192.168.0.1
if you want the ID to be of type _IPV4_ADDR_. Of course you could include both if you want the ID to be of type _IPV4_ADDR_. Of course you could include both
ID types with ID types with
subjectAltName=DNS:moon.strongswan.org,IP:192.168.0.1 subjectAltName=DNS:moon.strongswan.org,IP:192.168.0.1
but the use of an IP address for the identification of a host should be but the use of an IP address for the identification of a host should be
discouraged anyway. discouraged anyway.
@ -302,15 +302,15 @@ discouraged anyway.
For user certificates the appropriate ID type is _RFC822_ADDR_ which can be For user certificates the appropriate ID type is _RFC822_ADDR_ which can be
specified as specified as
subjectAltName=email:carol@strongswan.org subjectAltName=email:carol@strongswan.org
or if the user's e-mail address is part of the subject's distinguished name or if the user's e-mail address is part of the subject's distinguished name
subjectAltName=email:copy subjectAltName=email:copy
Now the certificate request can be signed by the CA with the command Now the certificate request can be signed by the CA with the command
openssl ca -in hostReq.pem -days 730 -out hostCert.pem -notext openssl ca -in hostReq.pem -days 730 -out hostCert.pem -notext
If you omit the `-days` option then the `default_days` value (365 days) If you omit the `-days` option then the `default_days` value (365 days)
specified in `openssl.cnf` is used. The `-notext` option avoids that a human specified in `openssl.cnf` is used. The `-notext` option avoids that a human
@ -351,17 +351,17 @@ Usually, a Windows or Mac OS X (or iOS) based VPN client needs its private key,
its host or user certificate, and the CA certificate. The most convenient way its host or user certificate, and the CA certificate. The most convenient way
to load this information is to put everything into a PKCS#12 container: to load this information is to put everything into a PKCS#12 container:
openssl pkcs12 -export -inkey carolKey.pem \ openssl pkcs12 -export -inkey carolKey.pem \
-in carolCert.pem -name "carol" \ -in carolCert.pem -name "carol" \
-certfile strongswanCert.pem -caname "strongSwan Root CA" \ -certfile strongswanCert.pem -caname "strongSwan Root CA" \
-out carolCert.p12 -out carolCert.p12
### Generating a CRL ### ### Generating a CRL ###
An empty CRL that is signed by the CA can be generated with the command An empty CRL that is signed by the CA can be generated with the command
openssl ca -gencrl -crldays 15 -out crl.pem openssl ca -gencrl -crldays 15 -out crl.pem
If you omit the `-crldays` option then the `default_crl_days` value (30 days) If you omit the `-crldays` option then the `default_crl_days` value (30 days)
specified in `openssl.cnf` is used. specified in `openssl.cnf` is used.
@ -369,7 +369,7 @@ specified in `openssl.cnf` is used.
If you prefer the CRL to be in binary DER format then this conversion If you prefer the CRL to be in binary DER format then this conversion
can be achieved with can be achieved with
openssl crl -in crl.pem -outform DER -out cert.crl openssl crl -in crl.pem -outform DER -out cert.crl
The strongSwan PKI tool provides the `--signcrl` command to sign CRLs. The strongSwan PKI tool provides the `--signcrl` command to sign CRLs.
@ -383,19 +383,19 @@ will be determined.
A specific host certificate stored in the file `host.pem` is revoked with the A specific host certificate stored in the file `host.pem` is revoked with the
command command
openssl ca -revoke host.pem openssl ca -revoke host.pem
Next the CRL file must be updated Next the CRL file must be updated
openssl ca -gencrl -crldays 60 -out crl.pem openssl ca -gencrl -crldays 60 -out crl.pem
The content of the CRL file can be listed with the command The content of the CRL file can be listed with the command
openssl crl -in crl.pem -noout -text openssl crl -in crl.pem -noout -text
in the case of a Base64 CRL, or alternatively for a CRL in DER format in the case of a Base64 CRL, or alternatively for a CRL in DER format
openssl crl -inform DER -in cert.crl -noout -text openssl crl -inform DER -in cert.crl -noout -text
Again the `--signcrl` command of the strongSwan PKI tool may also be used to Again the `--signcrl` command of the strongSwan PKI tool may also be used to
create new CRLs containing additional certificates. create new CRLs containing additional certificates.
@ -412,15 +412,15 @@ assume throughout this document that the strongSwan security gateway is **left**
and the peer is **right** then we can write and the peer is **right** then we can write
conn %default conn %default
leftcert=moonCert.pem leftcert=moonCert.pem
# load connection definitions automatically # load connection definitions automatically
auto=add auto=add
The X.509 certificate by which the strongSwan security gateway will authenticate 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 itself by sending it in binary form to its peers as part of the Internet Key
Exchange (IKE) is specified in the line Exchange (IKE) is specified in the line
leftcert=moonCert.pem leftcert=moonCert.pem
The certificate can either be stored in Base64 PEM-format or in the binary 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 DER-format. Irrespective of the file suffix the correct format will be
@ -443,8 +443,8 @@ As an ID for the VPN gateway we recommend the use of a Fully Qualified Domain
Name (FQDN) of the form Name (FQDN) of the form
conn rw conn rw
right=%any right=%any
leftid=moon.strongswan.org leftid=moon.strongswan.org
**Important**: When a FQDN identifier is used it must be explicitly included as **Important**: When a FQDN identifier is used it must be explicitly included as
a so called _subjectAltName_ of type _dnsName_ (`DNS:`) in the certificate a so called _subjectAltName_ of type _dnsName_ (`DNS:`) in the certificate
@ -456,14 +456,14 @@ 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 and which can be written e.g. in the LDAP-type format
conn rw conn rw
right=%any right=%any
leftid="C=CH, O=strongSwan, CN=moon.strongswan.org" 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 Since the subject's DN is part of the certificate, the `leftid` does not have to
be declared explicitly. Thus the entry be declared explicitly. Thus the entry
conn rw conn rw
right=%any right=%any
automatically assumes the subject DN of `leftcert` to be the host ID. automatically assumes the subject DN of `leftcert` to be the host ID.
@ -474,16 +474,16 @@ strongSwan supports multiple local host certificates and corresponding
RSA private keys: RSA private keys:
conn rw1 conn rw1
right=%any right=%any
rightid=peer1.domain1 rightid=peer1.domain1
leftcert=myCert1.pem leftcert=myCert1.pem
# leftid is DN of myCert1 # leftid is DN of myCert1
conn rw2 conn rw2
right=%any right=%any
rightid=peer2.domain2 rightid=peer2.domain2
leftcert=myCert2.pem leftcert=myCert2.pem
# leftid is DN of myCert2 # leftid is DN of myCert2
When _peer1_ initiates a connection then strongSwan will send _myCert1_ and will When _peer1_ initiates a connection then strongSwan will send _myCert1_ and will
sign with _myKey1_ defined in `/etc/ipsec.secrets` (see below) whereas sign with _myKey1_ defined in `/etc/ipsec.secrets` (see below) whereas
@ -497,7 +497,7 @@ have dozens of road warriors connecting to a central strongSwan security
gateway. The following most simple statement: gateway. The following most simple statement:
conn rw conn rw
right=%any right=%any
defines the general roadwarrior case. The line `right=%any` literally means 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 that any IPsec peer is accepted, regardless of its current IP source address and
@ -515,7 +515,7 @@ 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 field of the peer's certificate. One of the two possible representations of a
Distinguished Name (DN) is the LDAP-type format Distinguished Name (DN) is the LDAP-type format
rightid="C=CH, O=strongSwan IPsec, CN=sun.strongswan.org" rightid="C=CH, O=strongSwan IPsec, CN=sun.strongswan.org"
Additional whitespace can be added everywhere as desired since it will be Additional whitespace can be added everywhere as desired since it will be
automatically eliminated by the parser. An exception is the single whitespace automatically eliminated by the parser. An exception is the single whitespace
@ -524,12 +524,12 @@ between individual words, like e.g. in `strongSwan IPsec`, which is preserved.
The Relative Distinguished Names (RDNs) can alternatively be separated by a The Relative Distinguished Names (RDNs) can alternatively be separated by a
slash `/` instead of a comma `,` slash `/` instead of a comma `,`
rightid="/C=CH/O=strongSwan IPsec/CN=sun.strongswan.org" rightid="/C=CH/O=strongSwan IPsec/CN=sun.strongswan.org"
This is the representation extracted from the certificate by the OpenSSL This is the representation extracted from the certificate by the OpenSSL
`-subject` command line option `-subject` command line option
openssl x509 -in sunCert.pem -noout -subject openssl x509 -in sunCert.pem -noout -subject
The following RDNs are supported by strongSwan The following RDNs are supported by strongSwan
@ -572,12 +572,12 @@ and `10.1.3.0/24` behind the security gateway then the following connection
definitions will make this possible definitions will make this possible
conn rw1 conn rw1
right=%any right=%any
leftsubnet=10.1.0.0/24 leftsubnet=10.1.0.0/24
conn rw3 conn rw3
right=%any right=%any
leftsubnet=10.1.3.0/24 leftsubnet=10.1.3.0/24
For IKEv2 connections this can even be simplified by using For IKEv2 connections this can even be simplified by using
@ -591,35 +591,35 @@ access can be controlled by explicitly putting a roadwarrior entry for each
eligible peer into `ipsec.conf`: eligible peer into `ipsec.conf`:
conn sun conn sun
right=%any right=%any
rightid=sun.strongswan.org rightid=sun.strongswan.org
conn carol conn carol
right=%any right=%any
rightid=carol@strongswan.org rightid=carol@strongswan.org
conn dave conn dave
right=%any right=%any
rightid="C=CH, O=strongSwan, CN=dave@strongswan.org" 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 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 well. This entry is mandatory when the strongSwan host wants to act as the
initiator of an IPsec connection. initiator of an IPsec connection.
conn sun conn sun
right=192.168.0.2 right=192.168.0.2
rightid=sun.strongswan.org rightid=sun.strongswan.org
conn carol conn carol
right=192.168.0.100 right=192.168.0.100
rightid=carol@strongswan.org rightid=carol@strongswan.org
conn dave conn dave
right=192.168.0.200 right=192.168.0.200
rightid="C=CH, O=strongSwan, CN=dave@strongswan.org" rightid="C=CH, O=strongSwan, CN=dave@strongswan.org"
conn venus conn venus
right=192.168.0.50 right=192.168.0.50
In the last example the ID types _FQDN_, _RFC822_ADDR_, _DER_ASN1_DN_ and In the last example the ID types _FQDN_, _RFC822_ADDR_, _DER_ASN1_DN_ and
_IPV4_ADDR_, respectively, were used. Of course all connection definitions _IPV4_ADDR_, respectively, were used. Of course all connection definitions
@ -638,23 +638,23 @@ roadwarriors _rw1_ to _rw3_ connecting to a strongSwan security gateway the
following entries are required in `/etc/ipsec.conf`: following entries are required in `/etc/ipsec.conf`:
conn rw1 conn rw1
right=%any right=%any
righsubnet=10.4.0.5/32 righsubnet=10.4.0.5/32
conn rw2 conn rw2
right=%any right=%any
rightsubnet=10.4.0.47/32 rightsubnet=10.4.0.47/32
conn rw3 conn rw3
right=%any right=%any
rightsubnet=10.4.0.128/28 rightsubnet=10.4.0.128/28
Because the charon daemon uses narrowing (even for IKEv1) these three entries Because the charon daemon uses narrowing (even for IKEv1) these three entries
can be reduced to the single connection definition can be reduced to the single connection definition
conn rw conn rw
right=%any right=%any
rightsubnet=10.4.0.0/24 rightsubnet=10.4.0.0/24
Any host will be accepted (of course after successful authentication based on 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 the peer's X.509 certificate only) if it declares a client subnet lying totally
@ -670,8 +670,8 @@ 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 IP address from the `10.5.0.0/24` subnet `conn rw` can be defined as
conn rw conn rw
right=%any right=%any
rightsourceip=10.5.0.0/24 rightsourceip=10.5.0.0/24
### Protocol and Port Selectors ### ### Protocol and Port Selectors ###
@ -684,30 +684,30 @@ For IKEv2 multiple such restrictions can also be configured in
Some examples: Some examples:
conn icmp conn icmp
right=%any right=%any
rightprotoport=icmp rightprotoport=icmp
leftid=moon.strongswan.org leftid=moon.strongswan.org
leftprotoport=icmp leftprotoport=icmp
conn http conn http
right=%any right=%any
rightprotoport=6 rightprotoport=6
leftid=moon.strongswan.org leftid=moon.strongswan.org
leftprotoport=6/80 leftprotoport=6/80
conn l2tp conn l2tp
right=%any right=%any
# with port wildcard for interoperability with certain L2TP clients # with port wildcard for interoperability with certain L2TP clients
rightprotoport=17/%any rightprotoport=17/%any
leftid=moon.strongswan.org leftid=moon.strongswan.org
leftprotoport=17/1701 leftprotoport=17/1701
conn dhcp conn dhcp
right=%any right=%any
rightprotoport=udp/bootpc rightprotoport=udp/bootpc
leftid=moon.strongswan.org leftid=moon.strongswan.org
leftsubnet=0.0.0.0/0 #allows DHCP discovery broadcast leftsubnet=0.0.0.0/0 #allows DHCP discovery broadcast
leftprotoport=udp/bootps leftprotoport=udp/bootps
Protocols and ports can be designated either by their numerical values Protocols and ports can be designated either by their numerical values
or by their acronyms defined in `/etc/services`. or by their acronyms defined in `/etc/services`.
@ -742,24 +742,24 @@ The IPsec policy defined above can now be enforced with the following three
IPsec security associations: IPsec security associations:
conn sales conn sales
right=%any right=%any
rightid="C=CH, O=ACME, OU=Sales, CN=*" rightid="C=CH, O=ACME, OU=Sales, CN=*"
rightsourceip=10.1.0.0/24 # Sales IP range rightsourceip=10.1.0.0/24 # Sales IP range
leftsubnet=10.0.0.0/24 # Sales subnet leftsubnet=10.0.0.0/24 # Sales subnet
conn research conn research
right=%any right=%any
rightid="C=CH, O=ACME, OU=Research, CN=*" rightid="C=CH, O=ACME, OU=Research, CN=*"
rightsourceip=10.1.1.0/24 # Research IP range rightsourceip=10.1.1.0/24 # Research IP range
leftsubnet=10.0.1.0/24 # Research subnet leftsubnet=10.0.1.0/24 # Research subnet
conn web conn web
right=%any right=%any
rightid="C=CH, O=ACME, OU=*, CN=*" rightid="C=CH, O=ACME, OU=*, CN=*"
rightsubnet=10.1.0.0/23 # Remote access IP range rightsubnet=10.1.0.0/23 # Remote access IP range
leftsubnet=10.0.2.100/32 # Web server leftsubnet=10.0.2.100/32 # Web server
rightprotoport=tcp # TCP protocol only rightprotoport=tcp # TCP protocol only
leftprotoport=tcp/http # TCP port 80 only leftprotoport=tcp/http # TCP port 80 only
The `*` character is used as a wildcard in relative distinguished names (RDNs). 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 In order to match a wildcard template, the _ID_DER_ASN1_DN_ of a peer must
@ -788,24 +788,24 @@ to specific client host and subnets can be controlled on the basis of the CA
that issued the peer certificate that issued the peer certificate
conn sales conn sales
right=%any right=%any
rightca="C=CH, O=ACME, OU=Sales, CN=Sales CA" rightca="C=CH, O=ACME, OU=Sales, CN=Sales CA"
rightsourceip=10.1.0.0/24 # Sales IP range rightsourceip=10.1.0.0/24 # Sales IP range
leftsubnet=10.0.0.0/24 # Sales subnet leftsubnet=10.0.0.0/24 # Sales subnet
conn research conn research
right=%any right=%any
rightca="C=CH, O=ACME, OU=Research, CN=Research CA" rightca="C=CH, O=ACME, OU=Research, CN=Research CA"
rightsourceip=10.1.1.0/24 # Research IP range rightsourceip=10.1.1.0/24 # Research IP range
leftsubnet=10.0.1.0/24 # Research subnet leftsubnet=10.0.1.0/24 # Research subnet
conn web conn web
right=%any right=%any
rightca="C=CH, O=ACME, CN=ACME Root CA" rightca="C=CH, O=ACME, CN=ACME Root CA"
rightsubnet=10.1.0.0/23 # Remote access IP range rightsubnet=10.1.0.0/23 # Remote access IP range
leftsubnet=10.0.2.100/32 # Web server leftsubnet=10.0.2.100/32 # Web server
rightprotoport=tcp # TCP protocol only rightprotoport=tcp # TCP protocol only
leftprotoport=tcp/http # TCP port 80 only leftprotoport=tcp/http # TCP port 80 only
In the example above, the connection _sales_ can be used by peers In the example above, the connection _sales_ can be used by peers
presenting certificates issued by the Sales CA, only. In the same way, presenting certificates issued by the Sales CA, only. In the same way,
@ -820,15 +820,15 @@ 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 by default it is set to the issuer field of the certificate loaded via
`leftcert`. The statement `leftcert`. The statement
rightca=%same rightca=%same
sets the CA requested from the peer to the CA used by the left side itself sets the CA requested from the peer to the CA used by the left side itself
as e.g. in as e.g. in
conn sales conn sales
right=%any right=%any
rightca=%same rightca=%same
leftcert=mySalesCert.pem leftcert=mySalesCert.pem
## Configuring certificates and CRLs ## ## Configuring certificates and CRLs ##
@ -843,7 +843,7 @@ by a root CA, but strongSwan also supports multi-level hierarchies with
intermediate CAs in between. All CA certificates belonging to a trust chain 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 must be copied in either binary DER or Base64 PEM format into the directory
/etc/ipsec.d/cacerts/ /etc/ipsec.d/cacerts/
### Installing optional certificate revocation lists (CRLs) ### ### Installing optional certificate revocation lists (CRLs) ###
@ -903,7 +903,7 @@ the CRL distribution points contained in X.509 certificates.
The `ipsec.conf` option The `ipsec.conf` option
config setup config setup
cachecrls=yes cachecrls=yes
activates the local caching of CRLs that were dynamically fetched from an activates the local caching of CRLs that were dynamically fetched from an
HTTP or LDAP server. Cached copies are stored in `/etc/ipsec.d/crls` using a HTTP or LDAP server. Cached copies are stored in `/etc/ipsec.d/crls` using a
@ -928,9 +928,9 @@ In the simplest OCSP setup, a default URI under which the OCSP server for a
given CA can be accessed is defined in `ipsec.conf`: given CA can be accessed is defined in `ipsec.conf`:
ca strongswan ca strongswan
cacert=strongswanCert.pem cacert=strongswanCert.pem
ocspuri=http://ocsp.strongswan.org:8880 ocspuri=http://ocsp.strongswan.org:8880
auto=add auto=add
The HTTP port can be freely chosen. The HTTP port can be freely chosen.
@ -1013,8 +1013,8 @@ the `strictcrlpolicy` option. This is done in the `config setup` section
of the `ipsec.conf` file: of the `ipsec.conf` file:
config setup config setup
strictcrlpolicy=yes strictcrlpolicy=yes
... ...
A certificate received from a peer will not be accepted if no corresponding A certificate received from a peer will not be accepted if no corresponding
CRL or OCSP response is available. And if an IKE SA re-negotiation takes CRL or OCSP response is available. And if an IKE SA re-negotiation takes
@ -1037,13 +1037,13 @@ keyword for the peer side, the connection definitions presented earlier can
alternatively be written as alternatively be written as
conn sun conn sun
right=%any right=%any
rightid=sun.strongswan.org rightid=sun.strongswan.org
rightcert=sunCert.cer rightcert=sunCert.cer
conn carol conn carol
right=192.168.0.100 right=192.168.0.100
rightcert=carolCert.der rightcert=carolCert.der
If the peer certificates are loaded locally then there is no need to send any If the peer certificates are loaded locally then there is no need to send any
certificates to the other end via the IKE protocol. Especially if self-signed certificates to the other end via the IKE protocol. Especially if self-signed