We now support OpenSSL's implementation in the openssl plugin. This
makes sure our plugin is used on at least one of the hosts if we ever
switch to an OpenSSL version that supports ML-KEM.
In the ikev2/rw-mlkem scenario the logic is reversed. There the ml plugin
is preferred on moon to test the responder side (and carol for the
initiator) and dave will switch to OpenSSL if it ever provides ML-KEM.
}
charon-systemd {
- load = nonce openssl ml pem revocation constraints pubkey curl kernel-netlink socket-default updown vici
+ load = nonce ml openssl pem revocation constraints pubkey curl kernel-netlink socket-default updown vici
rsa_pss = yes
}
# /etc/strongswan.conf - strongSwan configuration file
swanctl {
- load = botan pem x509 revocation constraints pubkey
+ load = pem pkcs1 x509 revocation constraints pubkey openssl random
}
charon-systemd {
- load = nonce pem pkcs1 openssl ml revocation constraints pubkey curl kernel-netlink socket-default updown vici
+ load = nonce pem pkcs1 ml openssl revocation constraints pubkey curl kernel-netlink socket-default updown vici
rsa_pss = yes
}
# /etc/strongswan.conf - strongSwan configuration file
swanctl {
- load = pem botan x509 revocation constraints pubkey
+ load = pem pkcs1 x509 revocation constraints pubkey openssl random
}
charon-systemd {
- load = nonce pem pkcs1 openssl ml revocation constraints pubkey curl kernel-netlink socket-default updown vici
+ load = nonce pem pkcs1 ml openssl revocation constraints pubkey curl kernel-netlink socket-default updown vici
rsa_pss = yes
}
}
charon-systemd {
- load = nonce openssl ml pem revocation constraints pubkey curl kernel-netlink socket-default updown vici
+ load = nonce ml openssl pem revocation constraints pubkey curl kernel-netlink socket-default updown vici
rsa_pss = yes
}