For the purposes of creating a VPN, I can't find a logical explanation of OpenSSL's/x509 scheme. I'm royally confused about these three terms,

  1. Certificate Authorities
  2. Gateway certificates
  3. End-point Certificates.

I've read both Openswan: Building and Integrating Virtual Private Networks, and Building Linux Virtual Private Networks (VPNS). Both of these books in my mind presume an enormous amount of knowledge that the average programmer doesn't have, namely how does OpenSSL's x509 stuff work. I understand the basics of Public Key encryption, sending your public key, having the recipient encrypt their message to you which can only be decrypted with your private key. I've read the other answers here too, so let me specify my areas of confusion.

Should I think of a OpenSSL Certs as,

Certificate Authority → Gateway Certificate → End-point Certificate


Certificate Authority → Gateway Certificate

Certificate Authority → End-point Certificate

It comes down to this,

Does the self-signed CA sign the Gateway Cert which signs the End-point (client) certs? Or, does the CA sign all of the certs directly? Does the Gateway Cert have any direct relationship to the client-cert, or is that just an element of configuration in the VPN?

2 Answers 2


In X.509 certificates, there are Certification Authorities and End Entities. A CA is a system/organization which owns a public/private key pair and uses it to issue certificates, that is, sign them. A certificate binds an identity to a public key, and the job of the CA is to assert such bindings. You use the public key of a CA to verify the signature on a certificate. The public key of a CA can, in turn, be bound to the CA name by virtue of them being stored in a certificate, signed by a super-CA. This process is recursive, so you will end up, in practice, with certificate chains beginning with a "ultimate CA" (normally called "root CA" or "trust anchor") that you trust ex nihilo (it is hardcoded in the software or its configuration files), then a number of certificates, each containing the public key used to verify the signature on the next. All the certificates in the chain are necessarily CA certificate, except possibly the last one.

The last certificate in the chain is then called "end-entity" because it designates a system/organization which is not in the business of issuing certificates, but is "something else", for instance a VPN server. Since the end-entity key is not used to sign other certificates, the end-entity certificate necessarily appears last in the chain, hence its name.

In a VPN, there are end-points and gateways. A gateway is a machine which accepts connections from other systems (end-points, and other gateways), and forwards traffic on behalf of the connected system. An end-point does not indulge in forwarding; it sees only its own inbound and outbound traffic. The StrongSwan documentation begins with a rather self-explanatory diagram. End-points are application servers and desktop computers, while gateways are structural elements which route data.

Gateways (and, possibly, some end-points) need private/public key pairs, and the other systems must be able to verify that a given public key is indeed owned by a specific gateway or end-point. This calls for PKI and certificates. All these gateway and private/public key pairs are used to "do VPN", certainly not to issue certificates for other people, so they are all end-entities, as far as X.509 is concerned.

Certification and VPN structure are orthogonal. The certificates are used to assert bindings between names and public keys. There is no need for a CA to be located on a server which is also a router or gateway; there is actually no need for a CA to be online at all. Also, there is no need for a gateway to act as a CA: the gateway is meant to forward network traffic, not to make statements on the identity of other systems. You can conflate both roles and make a gateway also a CA, but this is very artificial, it is not needed in any way, and it will increase confusion.


The PKI structure isn't fixed; you can make it whatever fits your particular needs. But typically each client ships with a single trust root, that being either the VPN host's own certificate, or a certificate which signed it.

Client certificates are typically also signed by a single trust root, which qualifies them as authorized certificates.

But this isn't a hard-and-fast rule. Each installation is free to configure things as they choose.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .