1

I'm reading this tutorial which says,

Your gateway certificate must have: An Extended Key Usage flag explicitly allowing the certificate to be used for authentication purposes. The serverAuth EKU having the OID 1.3.6.1.5.5.7.3.1 (often called TLS Web server authentication) will do that. If you are using OpenSSL to generate your certificates then include the option

However, I'm confused as to what gateway certificate means? Are they referring to the CA, the server's private key, or the public key you send to the client?

The argument they want --flag serverAuth is valid in both

I don't understand the difference between --self and --issue

MadHatter
  • 79,770
  • 20
  • 184
  • 232
Evan Carroll
  • 2,373
  • 10
  • 34
  • 53

2 Answers2

1

ipsec pki --self is used to create a self-signed certificate. This means the certificate is signed with the private key that matches the public key contained in the certificate. This can be used for any certificate not just CA certificates, but it requires that the certificate is installed on all hosts that have to trust it.

ipsec pki --issue on the other hand uses a different key to sign the certificates. Its main use is for a CA to issue/sign end-entity certificates (or intermediate CA certificates). This makes deployment easier as you just have to install the CA certificate to trust all certificates issued by that CA.

Since both commands create new certificates the serverAuth Extended Key Usage flag (--flag serverAuth) is a valid option for both. Which command you use to create your end-entity certificates is up to you, for easier deployment the second option is recommended.

Likewise, the --san ... option mentioned in the tutorial adds a subjectAltName extension to a certificate, so it too can be used with both commands.

ecdsa
  • 3,973
  • 15
  • 29
  • Could you show how to create an end-user cert with `ipsec pki --self`, in comparison to `ipsec pki --issue` assuming both have a CA that is installed on all hosts? – Evan Carroll Jul 30 '13 at 07:56
  • @EvanCarroll Creating self-signed end-entity certificates does not involve a CA as the certificates are, well, self-signed by the private key that belongs to the public key that is included in the respective certificate. As opposed to the second case where the certificates are signed by the private key of the CA. – ecdsa Jul 30 '13 at 12:41
0

A certificate is essentially your server's public key (with a few additional fields) that has been signed by your CA. The certificate file traditionally has a .crt extension, and is in the format:

-----BEGIN CERTIFICATE-----
MII...<snip>
-----END CERTIFICATE-----

By "gateway", they are referring to your IPSec gateway.

EEAA
  • 109,363
  • 18
  • 175
  • 245
  • So I create a CA, which is just a private key in and of itself. Then I create a new private key/public key pair for the gateway, I sign that public key generated with the private key of the CA to generate the "certificate" for the gateway, it's in the act of signing the generated public key with the CA that I need to give the argument to add the EKU? – Evan Carroll Jul 29 '13 at 19:36
  • @EvanCarroll What tools did you use to create the keys and certificates? If you used the `ipsec pki` utility you might want to follow [this tutorial](http://wiki.strongswan.org/projects/strongswan/wiki/SimpleCA). And a CA is not just a private key, it also comprises a self-signed certificate (signed with said private key). And yes, it's in the step of issuing/signing the end-entity certificate where such EKU extensions are added to the certificates (it could also be a two step process involving a certificate request that contains all the information needed by the CA to issue the certificate). – ecdsa Jul 29 '13 at 20:37
  • and is it in the `ipsec pki --issue` that I'd indicated `--flag serverAuth`? – Evan Carroll Jul 29 '13 at 20:46
  • @ecdsa I've updated the question. – Evan Carroll Jul 29 '13 at 20:56