0

Using PKI tool from strongswan to setup a CA. Trying to setup the OCSP side of things have run into many issues as per another thread I posted (Strongswan PKI - ED25519 Certifcates - OCSP Responder having issues). Now I am looking at how to add stapling.

Is there a way of creating certificates with strongswan pki that use the MustStaple Extension or as the latest openssl refers to it status_request?

I can't seem to find the documentation on it nor any information on it. Can't even find out how to add extensions to the certificate with strongswan pki.

shinooni
  • 33
  • 4

1 Answers1

1

The X.509 extension you refer to is actually called "TLS feature extension" and is defined in RFC 7633. If defined, it contains a list of TLS extension identifiers of which one might be status_request. So it's quite specific to TLS.

Likewise, OCSP stapling is a feature of TLS (via its Certificate Status Request extension as defined in RFC 6066) so it's not directly applicable to IKEv2.

However, there is a similar feature defined in RFC 4806, which allows exchanging OCSP responses during IKEv2 authentication. strongSwan currently doesn't support it, though.

For these reasons the extension is currently not relevant to strongSwan, which is why the pki tool doesn't provide support for it.

Community
  • 1
ecdsa
  • 3,973
  • 15
  • 29
  • Okay that is unfortunate as I am trying to deploy a Ed25519 Certificate and OpenSSL wouldn't create the certificates. Is there a tool that I can use that does support it for ed25519 certificates? – shinooni May 07 '18 at 04:20
  • You could always use a newer version of OpenSSL that supports Ed25519 to generate your certificates (e.g. in a Docker container). – ecdsa May 07 '18 at 08:17
  • Is it just the docker container one? because when i built with the April 2018 release it had ed25519 as an algorithm option but not for any thing else like CA, x509, ecparam or ec. The only thing that was available to use Ed25519 for was req. Unless there was some configuration I was meant to do? to get those other commands working with ed25519 – shinooni May 07 '18 at 11:21
  • No, Docker was just a suggestion if you didn't want to mess with the OpenSSL version installed on your system. Just use a new enough version (install it on your system, use Docker, whatever...) and you should be able to use Ed25519 for the certificates (that's at least what [this ticket](https://github.com/openssl/openssl/issues/487) and this [related one](https://github.com/openssl/openssl/pull/3503) suggest). – ecdsa May 07 '18 at 12:41
  • So below is what ive used to generate the root CA and under this comment I will add the intermediary which is where it falls apart. `sudo openssl genpkey -algorithm ED25519 -out private/ca.cheese.key.pem` to generate the private key for the root ca `sudo openssl genpkey -algorithm ED25519 -out intermediate/private/int.cheese.key.pem` to generate the private key for the intermediary `sudo openssl req -config openssl_root.cnf -new -x509 -extensions v3_ca -key private/ca.cheese.key.pem -out certs/ca.cheese.crt.pem`to create the root ca certificate. – shinooni May 07 '18 at 17:19
  • `openssl req -config intermediate/openssl_intermediate.cnf -new -key intermediate/private/int.cheese.key.pem -out intermediate/csr/int.cheese.csr` this is the generate the csr in preparation for getting the certificate signed `openssl ca -config openssl_root.cnf -extensions v3_intermediate_ca -days 3600 -md sha256 -in intermediate/csr/int.cheese.csr -out intermediate/certs/int.cheese.crt.pem` This is where it falls appart with 140523012273920:error:1010F08A:elliptic curve routines:pkey_ecd_ctrl:invalid digest type:crypto/ec/ecx_meth.c:783 When attempting debug - removing md does not work – shinooni May 07 '18 at 17:26
  • Or should I be closing this question and creating a new one ? As this seems to be a bit away from strong Swan now – shinooni May 07 '18 at 22:45
  • You should definitely remove `-md`, but also make sure you don't have `default_md` set anywhere in `openssl_root.cnf` (Ed25519 always uses SHA2-512). – ecdsa May 08 '18 at 06:51
  • I have made sure in both intermediary and root ca cnf files make no mention to digest files. However I get an error message even after regenerating root and intermediary req files. The error is as follows `no default digest 139869736675072:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group= name=unique_subject` This reads to me like it needs the message digest to be there in some manner; ive tried parsing NULL to it, tried just giving it garbage, tried SHA2-512. All didn't work. Any ideas? – shinooni May 08 '18 at 09:57
  • I guess, there are some changes missing to make this work. Compared to `req`, the `ca` command seems to insist on a digest. `req` on the other hand is perfectly fine passing NULL when singing, which is what OpenSSL's Ed25519 implementation [apparently requires](https://github.com/openssl/openssl/blob/8c8fbca92dc95bb8672dea194bbe414059a874d2/crypto/ec/ecx_meth.c#L780), and which happens if you don't configure a digest in `[ req ] default_md` or via command line (like `ca`, it fails if you do). You should probably [file an issue](https://github.com/openssl/openssl/issues). – ecdsa May 08 '18 at 16:03
  • I guess you already saw, the problem with the `ca` command and Ed25519 is now [fixed](https://github.com/openssl/openssl/commit/f3021aca4a154c2ff9bd0030f7974eb6a719550d). – ecdsa May 22 '18 at 12:36
  • In fact I did not. Thank you for pointing that out. – shinooni May 23 '18 at 14:29