Feature #391

Add DNS CERT support

Added by Ruslan Marchenko about 5 years ago. Updated almost 5 years ago.

Target version:
Start date:
Due date:
Estimated time:


Add DNSSEC protected CERT RR delivered certificate authentication.
New dnscert plugin is based on ipseckey plugin and reuses most of its code
in particular plugin and credential enumerator part.
Plugin relies on existing PEM decoder as well as x509 and PGP parsers. As
such plugin expects PEM encoded PKIX or PGP certificate payload.
Certificate's pubkey algorithms are currently restricted to RSA family,
although it's not a hard restriction since strongswan is capable handling ECC
certificates. ECC can be fed using algorithm 0(Undefined) if required.

The plugin is targeted to improve interoperability with Racoon, which supports
this type of authetication, ignoring in-stream certificates and using only DNS
provided certificates for FQDN ID.

Aug 28 19:22:27 charon[32403]: 12[ENC] parsed ID_PROT response 0 [ ID SIG ]
Aug 28 19:22:27 charon[32403]: 12[CFG] performing a DNS query for DNSCERT RRs of ''
Aug 28 19:22:27 charon[32403]: 12[CFG]   using trusted certificate "C=CT, ST=City, O=Home,," 
Aug 28 19:22:27 charon[32403]: 12[IKE] authentication of '' with RSA successful
Aug 28 19:22:27 charon[32403]: 12[IKE] IKE_SA vex[1] established between[]...[]
Aug 28 19:22:27 charon[32403]: 12[IKE] IKE_SA vex[1] established between[]...[]
Aug 28 19:22:27 charon[32403]: 12[IKE] scheduling reauthentication in 9854s
Aug 28 19:22:27 charon[32403]: 12[IKE] maximum IKE_SA lifetime 10394s


#1 Updated by Ruslan Marchenko about 5 years ago

In the log excerpt above "" is running racoon with dnssec certificate option.

remote anonymous {
        exchange_mode main,base,aggressive;
        my_identifier fqdn "";
        certificate_type x509 "sun.pem" "sun.key";
        peers_certfile dnssec;
        send_cert off;
        send_cr off;

#2 Updated by Tobias Brunner about 5 years ago

  • Category set to libstrongswan
  • Status changed from New to Assigned
  • Assignee set to Tobias Brunner

#3 Updated by Ruslan Marchenko about 5 years ago

Sorry, I messed with indentation, here's amended patch with spaces replaced by tabs.

#4 Updated by Tobias Brunner about 5 years ago

  • Description updated (diff)
  • Status changed from Assigned to Feedback

Thanks for the patch.

In order for us to accept it in our main distribution you'd have to resubmit it under the MIT X11 license as described on the Contributions wiki page. If you are OK with that, just add the MIT header with your copyright right under the GPL header with Reto's copyright in the new files.

There are a few other issues:

  1. Retrieving the algorithm field does not seem to make much sense (especially skipping over keys). It seems mostly to be useful when using key tags, which is not the case here. Instead you should probably handle the case where the certificate can't be created, that is, *cert is NULL after calling the credential factory (the code in the ipseckey plugin doesn't do that at the moment and seems a bit odd anyway, I'm going to refactor that and could change your code when applying it, if you don't mind).
  2. Could you rename the cert_tag member to key_tag as that's what it is called in RFC 4398 (if used it's a tag calculated for the key in the certificate not the certificate itself).
  3. Reading the validity period from the RRSIG RR is not required here as the certificates contain their own timestamps, which is not the case with the raw keys in IPSECKEY RRs. Likewise, the identity does not have to be forwarded to the enumerator.
  4. Please don't add vim modelines to the code files. Instead, you could add something like this to your ~/.vimrc:
    autocmd BufNewFile,BufRead /path/to/strongswan/* set ts=4 sw=4 noet

#5 Updated by Ruslan Marchenko about 5 years ago

Hi Tobias,
Thanks for feedback. Algorithm pre-check indeed does not have much sense, its purpose is really to pre-validate next step where cert is going to be created. Although allowing algo 0 really negates whole purpose. Removed.
cert_tag - yes, I was going to rename but gave up idea since it aligned better with cert_type :) Renamed.
Validity/Id - I was going to use it for cert pre-validation to skip unsuitable certs (since CERT type does not allow seamless rollover) but agree it's useless overhead with current implementation anyway, better to peek inside the cert itself - which should be done by charon while enumerating certs. Removed.
vim modelines - removed.
License - added.

#6 Updated by Tobias Brunner about 5 years ago

  • Status changed from Feedback to Resolved
  • Target version set to 5.1.1
  • Resolution set to Fixed

Great, thanks for incorporating those changes.

I applied the patch to the dnssec branch, with some editorial changes (typos and such), one bug fix (you didn't clone the certificate chunk after reading it from the resource record), and all my changes I did in the ipseckey plugin yesterday. I hope you don't mind.

I will merge the branch next week, after doing some tests. Perhaps even with a test case in our test suite - there are already two for the IPSECKEY use case: ikev2/net2net-dnssec and ikev2/rw-dnssec.

#7 Updated by Ruslan Marchenko about 5 years ago

Thanks Tobias.
I was actually going to submit it as a second update to this patch where I fixed chunk stuff and added indirect certificate handling via fetcher mechanism. Not sure though if it is useful, just an RFC. Will rebase it on the branch if it reder itself useful. I still going to run some field tests for that to find how robust is it.

#8 Updated by Tobias Brunner almost 5 years ago

  • Status changed from Resolved to Closed

Merged to master.

Also available in: Atom PDF