Ok, Last try - 127.0.0.1 - the same thing, revoked certificate still works.
Upgraded to 7.1beta1 - the same thing.
So I've returned to this and found that the old (wiki) manual is really insufficient, and the new (Confluence) one even misleading, as it tells you to self-sign all certificates. The normal procedure is to create a Certification Authority (CA) certificate, which is self-signed, and use it to sign all the certificates to be used by servers and clients.
The following is tested on a CHR running ROS 6.47.9.
While signing the CA certificate, you can specify an IP address or FQDN to be used to create the complete url of the CRL to be included into the contents of the CA certificate to be generated, using the
ca-crl-host parameter. Unless you plan for a more complex setup, it must be one of the own IP addresses of the router that acts as the CA, or an FQDN resolving to one of that router's own addresses. To learn what the resulting url actually is, you have to export the CA certificate and use some certificate viewer. E.g. when I have specified
ca-crl-host=crl.home.me, the resulting url became
http://crl.home.me/crl/23.crl; apparently, the number is the sequence number of a certificate to be signed by that router, no matter whether a CA one or any other one. This file is generated by the router, and updated each time you revoke a certificate signed by that CA, but it is not accessible in the
file tree.
You can provide a comma-separated list of IP addresses or FQDNs, but only the first one on the list is actually used - there's just a single URL in the certificate.
In contrary to what I have seen on a screenshot in some related post on another forum, the link to that file doesn't dynamically appear in the
/certificate crl table on the router itself; you have to add it manually, using the
fingerprint of the CA certificate and the
url extracted from it, same like for a CRL of any external CA you want the router to use.
You also have to set
crl-download and
crl-use to
yes under
/certificate settings.
And it's only now that the router itself, when acting e.g. as an IPsec responder, is able to check whether the initiator's certificaters are not revoked.
The above is enough to let a router, acting as both a VPN server and a CA, reject incoming connections from clients presenting a revoked certificate. But if the CA is not colocated with the VPN server, the VPN server must be able to fetch the CRL from the CA, and in the ideal world, so should be the clients because the server may hypothetically get stolen too.
Unfortunately, you currently cannot separate the http server used to serve the CRL from the http server used for management access. So if you want to narrow the access to management while keeping access to the CRL widely open, you have to use layer7-protocol regexps to validate the url in the GET packets and eventually reset connections attempting to access other files from other than permitted sources.