StrongSwan: Establishing the certificate management
Why certificates?
This is a valid question since one could argue that a key would suffice to
secure an IPsec connection to keep out any troublemakers, that is, a scheme
similar to what is used in a WLAN is applied. This scheme would of course have
several advantages, because you would have to remember only the key and that
there's no certificate that could expire.
However, there's a critical catch on this: Whoever gets a hold of this key
automatically gains access to an IPsec connection thus protected, which
mandates changing the key – but the larger the IPsec network, the more
complicated it becomes to provide a new key to every station. Furthermore one
could forget one station or another which finds itself locked out.
On top of that the identity of a station cannot be biuniquely determined only
with a security key, and even if it is used for encrypting, a secure encryption
can only be achieved with a lot more effort.
In order to circumvent these problems, certificates come into play. Not only do they provide a key necessary for encryption, but they also contain an identification for the subscriber to whom the certificate has been issued as well as a time span during which the certificate is valid and an identification that identifies the certificate. It is furthermore possible to revoke a certificate so that it is rendered useless: This would be about the same as if the certificate was expired. This way any misuse can be signifcantly curtailed and making it drastically more difficult as well.
to the topPurchase or not?
The answer to this question essentially depends on why you want to establish
IPsec connections. If it solely serves connecting to your server, you may
simply spare yourself the trouble and the cost and use your own certificate. It
normally works as good as one that you have bought.
This is an entirely different story when you intend to commercially offer IPsec
connections, for example when you want to have your server act as a switching
center between the boxes of your customers. Here it is recommended to buy a
certificate, because a certification authority validates and attests your
domain – and possibly your identity as well. On top of that an approved
Certification Authority has the necessary means at its disposal to quickly
block compromised certificates so that nobody can cause any mischief with it;
this is important particularly for businesspeople.
Setting up your own Certificate Authority
When you want to follow the path of using your own certificates there are some
steps that you need to perform beforehand. You'll have to set up your own
Certificate Authority first so that you may issue certificates at your sole
discretion and also revoke them if necessary.
Furthermore a digital “signature” is necessary to confirm the authenticity of a
certificate so that it becomes trustworthy. Certificates without this signature
normally aren't trusted, and StrongSwan will refuse its cooperation and simply
reject the certificate.
However, it is necessary that the basis for these signatures stays exclusively
with you so that there's no way for anyone to issue any certificates in your
name and so gain access to your IPsec connections.
In order to get started you need to create a directory that is used solely for your certificate authority and therefore doesn't contain anything else, and also make sure to set the access rights so that no stranger gets access there (this is particularly relevant on computers to which multiple persons have access), best in root's home directory. This ensures that only you as system administrator can access the data that belongs to your certification authority.
The following instructions are derived from these original instructions at strongswan.org and allow for the problem that algorithms like SHA1 and MD5 have to be considered insecure as of now. On top of that a longer key also has its advantages.
to the topThe root certificate
To begin with you need to generate a root certificate on which you construct your entire certificate tree. This is performed in two steps and requires that you generate a key first.
- Open a text console and log in as root.
- Switch to the working directory of your certification authority.
- Execute the following command: ipsec pki --gen --size 4096 > cakey.der
- Execute the follofing command directly afterwards: ipsec pki --self --in cakey.der --dn "C=US, O=<your_org>, CN=<your_org> CA" --lifetime 10950 --digest sha256 --ca > cacert.der
This creates an RSA key with a length of 4096 bytes to begin with. It is the identification of your Certificate Authority: Never ever give it away, and do not put it on your server, under any circumstances! In order to determine the validity of your end certificates without any doubt you merely need the root certificate for your certificate tree so there's absolutely no need to copy this key to your server.
The second stage generates a certificate from your key. In order to do so the
key that you created before must be read in. It is furthermore necessary to
provide some additional data that affect the validity and security of your
certificate.
Since you deploy your root certificate to your server only and normally don't
give it away you may set the lifetime to a high value (here it's a little short
of thirty years that you don't have to consider renewing the root certificate)
and specify a hash algorithm stronger than SHA1 or MD5, because these two can
be cracked rather easily. Furthermore you have to set the identification that
is provided by the certificate to suit your situation. Set
C to the code that represents your country (here it
is US for the United States) and O to the name of
your organization. Do the same with the common name
(CN) of the entity you are providing the certificate
for. You are furthermore required to self-sign the root certificate to make it
valid so that it can be used as a point of origin for other certificates. Copy
the root certificate thus generated to the directory
/etc/ipsec.d/cacerts/ on your server.
Now you are set for the next step, however, you may insert additional tiers of certificates depending on the requirements of your IPsec infrastructure. It is advisable to introduce one, if not two, intermediate tiers that you may assign to distinct departments and sub-departments (which you may again name in the OU field of the identification) to sign the actual end certificates with if there are many departments. them.
to the topOptional: Intermediate certificates
These certificates are also authorized to sign, however, they don't reside at the root of the certificate tree, but their identity is confirmed by the root certificate. You need to enter the following two commands:
- ipsec pki --gen --size 4096 > intermediate-key.der
- ipsec pki --pub --in intermediate-key.der | ipsec pki --issue --cacert cacert.der --cakey cakey.der --dn "C=US, O=<your_org>, CN=<your_org> sub CA" --digest sha256 --lifetime 3650 --ca > intermediate-cert.der
+++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++
Never use the same key for multiple certificates! In
case you ever lose the key all certificates derived from it are suddenly
compromised and have to be regenerated, which in relation means a greater
effort for you!
Otherwise only one certificate could be compromised at any one time, which
allows you to revoke it and simply issue a new one so that the time and effort
required is rather low. In case an intermediate certificate is compromised
normally only a relatively small group is affected and new certificates are
reissued relatively quickly for its members.
However, things become significantly worse when the key for the root
certificate is purloined, because the entire certificate tree becomes insecure.
The only option in this case is to replace every single certificate starting
with the root certificate via all intermediate certificates to the end
certificates to prevent an attacker from establishing an unsolicited IPsec
connection! Always keep the keys necessary for those certificates that are
required to sign others at a safe location!
When you have created the intermediate certificate (which works similar to
creating a root certificate except that you need the root certificate and the
associated key to sign this certificate) you may either introduce additional
sub-tiers, which works exactly as described except that you need the
intermediate certificate you just created to sign the next lower tier, or you
can create end certificates for all participants in your IPsec infrastructure.
Then copy these intermediate certificates to
/etc/ipsec.d/cacerts/ as well. You can furthermore
pass these intermediate certificates together with their associated keys to
other persons that are responsible for the respective department so that they
in turn are able to issue end certificates without having to come back to you –
however, if the need arises, that is, something is going haywire in the
department you have issued the intermediate certificate for, you may invalidate
all certificates issued there simply by revoking the intermediate certificate
without having to touch the end certificates.
Note: Don't nest too many tiers between root and end certificates! First of all establishing a connection is unnecessarily delayed with each additional tier, and secondly you are going to bog down more the more tiers and branches you have to manage! Less is more in this case, plus it is always preferable to keep the certificate tree as compact as possible and only introduce those intermediate tiers that are absolutely necessary. Normally it's unnecessary to have more than two tiers, and normally one intermediate tier is entirely sufficient.
to the topThe server certificate
There are some strict standards that a certificate that is to be installed on a server must fulfill so that its authenticity can be confirmed. It is therefore mandatory that the identification is biuniquely associated to a particular server, i. e. that the server doesn't have multiple certificates that are assigned to it and that each certificate isn't installed on multiple servers simultaneously. If, contrary to expectations, the security measures are breached for a particular server, the affected certificate can be revoked and reissued without affecting any other servers in the IPsec network. This way you aren't entirely paralyzed, and an attacker could at worst wreak havoc on a single server. The other servers remain entirely unaffected by this.
You need to generate this certificate in two stages as well; the sole
difference to an intermediate certificate is that you cannot use it to sign
other subordinate certificates.
Please proceed as follows:
- ipsec pki --gen --size 4096 > serverkey.der
- ipsec pki --pub --in serverkey.der | ipsec pki --issue --cacert cacert.der --cakey cakey.der --dn "C=US, O=<your_org>, CN=<your_org entity>" --digest sha256 --lifetime 730 > servercert.der
In this example the server certificate is signed directly with the root
certificate. The advantage of this method is that you get an extremely shallow
tree structure. The disadvantage, however, is that when you have to revoke the
root certificate, all certificates cannot be used any more and have to be
renewed!
When you are working with an intermediate tier you don't have to replace the
root certificate, but it suffices to revoke the intermediate certificate of the
affected subtree to counter a problem. The rest stays active and can continue
working via IPsec.
When you intend to use intermediate certificates you have to replace
cacert.der and cakey.der
with the actual file names of the desired certificates in order to create the
end certificate. The process is otherwise identical in either case.
Once you have created the certificate just put it into the directory /etc/ipsec.d/certs/ on your server and copy the server key to /etc/ipsec.d/private/. Now all required certificates are installed on the server.
to the topThe user certificate
A user certificate is created essentially the same as a server certificate,
except that you should also provide an alternate name, which simplifies
authentication. Not only are you able to avoid specifying the entire
identification, but you can also work with wildcards when defining connections
server side and so grant an entire group of persons access – providing that
they can present a valid certificate for your IPsec connections.
It is nevertheless advisable to also check a user ID and the associated
password. Someone filching an end certificate and its associated key isn't per
se successful this way, but he has to tackle yet another obstacle to establish
an IPsec connection. However, the certificate in question should be revoked by
then.
To create a user certificate execute the following commands:
- ipsec pki --gen --size 4096 > userkey.der
- ipsec pki --pub --in userkey.der | ipsec pki --issue --cacert cacert.der --cakey cakey.der --dn "C=US, O=<your_org>, CN=<userid>" --san <userid> --digest sha256 --lifetime 730 > usercert.der
As you can see an alternate name has been provided that may be used for
verifying identities instead of the full identification. Usually an alternate
name is a user ID in the form <username>@<entity>, an e-mail
address, etc.
This ID must be identical to the user ID that you use for connecting to your
IPsec gateway lest StrongSwan complains and the connection is rejected.
In order to use this certificate you have to install it on
your personal box in the directory
/etc/ipsec.d/certs/ and the associated key in
/etc/ipsec.d/private/.
You need to install neither the root nor any intermediate certificates, because
the trust chain between the individual certificates is checked server-side. It
would furthermore be possible to connect to your IPsec network with a root or
intermediate certificate so it's generally not a viable option to pass them on
except it is absolutely necessary to do so.
Revoking certificates
It may be necessary every now and then to revoke an issued certificate that is
still valid, be it that someone has lost it or that it has been stolen together
with its associated key, be it that said person wants to permanently leave your
IPsec network or whatever the reason may be. In this case it's necessary to
revoke the affected certificate so that it cannot be used any more even though
it hasn't expired yet. When you have to revoke a given certificate, execute the
following command (please keep in mind that you have to have the certificate in
question available to be able to revoke it!):
ipsec pki --signcrl --cacert cacert.der --cakey cakey.der
--reason <reason> --cert usercert.der > crl.der
You may specify the following values as a reason:
Revocation reason | Meaning |
---|---|
key-compromise | The key from which the certificate has been derived has been cracked or stolen. The affected connection isn't secure any more. |
ca-compromise | The certification authority has been compromised, e. g. the key from which the affected certificate has been derived has been cracked or stolen. The affected certificate and everything below it isn't secure any more. |
affiliation-changed | The affected entity doesn't belong to your IPsec network any more, be it that it has completely left the network, be it that it has been relocated to another logical subsection of the network. Anyway, the certificate cannot be used any more. |
superseded | The certificate has been replaced by another one and isn't used any more. |
cessation-of-operation | The entity to which the certificate has been issued is shutting down. The certificate issued isn't necessary any more. |
certificate-hold | The certificate has been temporarily revoked. |
Subsequently put this revocation list into the directory /etc/ipsec.d/crls/. Then restart StrongSwan with systemctl restart strongswan.service and the certificate in question is revoked. Now it cannot be used any more to connect to your IPsec gateway.
to the topWould it be viable to act as a public Certificate Authority yourself?
In case that you are thinking about this, let me be candid:
Better let it alone; it would be in your interest.
When confidential data is concerned – and as soon as you are dealing with
cryptography you are coming very close to confidential data – you are walking
on particularly dangerous ground.
It may appear to be appealing to offer certificates yourself, but there are
many imponderabilia that cannot be overlooked in their entirety. It starts with
your server being subject to attacks from the Internet, and a server that hosts
a certification authority turns out to be a particularly tempting target for
any miscreants who, should an attack turn out to be successful, would thwart
your entire Certificate Authority and gain access to your IPsec connections
this way. After all they would be able to issue their own certificates on
behalf of your certification authority that they are going to use in your IPsec
network. Even worse: An attacker could eavesdrop the entire communication that
is believed to be protected by your certificates!
The question about liability is yet another delicate point. Because you cannot
per se dismiss any liability claims (gross neglect and intention are definitely
going to get you in as far as any compensations are concerned), and because it
have been your certificates that have been thwarted the resulting damage can
easily run into the millions. The question is whether or not your liability
insurance is going to cooperate at all when you frivolously issue certificates
to third parties.
The other question that inevitably arises is how you are going to reliably
check the legitimacy of a request from the 'Net. Designated certification
authorities have both the necessary personnel and the expertise required in
this field to get this done, but you as a lone warrior you are dealing with a
lost cause. And even though you may be issuing certificates only to persons you
know personally such an endeavor nevertheless constitutes an incalculable risk.
After all you have to guarantee at any time that the integrity of your
certification authority is preserved. This includes various security measures
on your server that prevent strangers from gaining access to your server and
also record and report any unusual activities. And should anyone gain
unsolicited access to your server you are to react as soon as possible, best
immediately, to correct the problem before anyone can wreak havoc with any
grifted information. In case of a certification authority that means that you
have to revoke all certificates.
However, should you still consider establishing a public certification
authority against all warning, please make sure to inquire on this problematic.
Make sure to consult an attorney in any case who can give you counsel on any
legal questions and also point out any legal pitfalls that are linked to this
topic. Also inquire at your insurance provider whether or not he is going to
settle any claims that may be caused and how much a liability insurance that
covers this would cost you. You furthermore may need the assistance of an IT
specialist who has expertise in security in the field of information technology
and is able to help you secure your server against any hacking attempts. Last
but not least: Always keep the operating system of your server up to date and
use only dedicated root servers for such an endeavor. This way you are
guaranteed to have exclusive access and nobody else can tamper with it.
However, you can be assured of one thing: This isn't going to be easy at all,
and you also have to allow for a considerable expenditure of time when you want
to be reasonably successful, especially since there is quite some competition
in this area.