OpenVPN on Chaos Calmer and revoking certificates

Hi, I have OpenVPN installed on Chaos Calmer.
openvpn-easy-rsa 2013-01-30-2|
openvpn-openssl 2.3.6-5

Setting up new certificates works fine, but revoking existing does not.

After using this example command:
openssl ca -config /etc/openvpn/ssl/openssl.cnf - revoke /etc/openvpn/ssl/1002.pem -keyfile /etc/openvpn ssl/ca.key -cert /etc/openvpn/ssl/ca.crt
... and restarting service.
I have updated index.txt file, but client still is able to connect to the OpenVPN server like before.
What am I doing wrong here?

All software is you've listed is unsupported (incl upstream) by now and the other software on your router have known security issues so I'd suggest that you update everything to a recent version and redo your certificates using openvpn-easy-rsa 3.X instead.

1 Like

Have you implemented a certificate revocation list (CRL)? Otherwise just updating the index does nothing. The server must point to the CRL during initial load. After that it can be dynamically updated.

From the easy-rsa folder you can issue ./revoke-full clientID, to revoke a certificate once a proper CRL is implemented.

As an aside, I find it very unhelpful to just advise people to upgrade to the latest version as a solution. Sure, it’s good advice, but looking at the original post (and it is lacking some details so we are drawing conclusions here) but a simple upgrade to latest isn’t going to solve an incorrect usage of the tools themselves.

That is valuable advice, but my router is TP-Link TL-WR1043N/ND v2 and it does not have any newer software released as I checked.(opkg list-upgradable shows nothing).
Besides that - the only service publicly available is OpenVPN service.
Are there any known issues that put on risk security of this configuration?

I believe I have not. I followed this guide:
And it has nothing about CRL.
Could you please point me to user guide about implementing CRL?

which would be expected as there hasn't been a fresh build of Chaos Calmer in years.

There are current builds for later releases for the TL-WR1043N v2, such as can be found at

and various users who build and share their own builds here on the forum.

Well, it is because easy-rsa 3.x doesn't work the same as the earlier versions in a good way and keeping people on old unsupported and unsecure software isn't helping rather the opposite.

This is probably undocumented officially but you can't keep your settings between your old version of OpenWrt due to limitations of sysupgrade so backup your router and start fresh. Due to how squashfs works it isn't possible to upgrade the OS itself as you do on full distros such as Debian, Ubuntu, *BSD etcs.


In your server.conf you need the following:
crl-verify $OPENVPN_DIR/crl.pem
Where $OPENVPN_DIR is your openvpn server directory. This will instruct your server to check all certificates against the provided CRL file. Note that the CRL file must be present (and valid) or the server will not start.

Any time a new client is added, you need to regenerate a CRL by the following:
openssl ca -gencrl -out keys/crl.pem -config "$KEY_CONFIG"
Where $KEY_CONFIG points to your openssl.cnf in the easy-rsa directory.
Now you can copy the generated CRL.pem to the openvpn_dir and start the server.

To revoke a certificate in the CRL, from the easy-rsa directory you can run
./revoke-full $client_id
where $client_id is the ID of the client to be revoked. This will update the CRL.pem which you should copy into the openvpn_dir.

You will note that your index file will change to reflect the status of each certificate being revoked. Technically, you can un-revoke a certificate, but it is bad practice and a bit of a hack. The proper method would be to generate a brand new certificate. If you were looking at more temporary ways of disabling clients from joining, a tls-verify script would be more appropriate.

I think i referenced the following blog when first working out my workflow:

If a user wants to stay on older software that is there choice (again, i'm not advocating it as the best choice. It may not always be their choice). Whilst the OS may not be supported anymore, the software running on it still is and the knowledge that the community holds (and the community is the support structure here) is still valid.

If you've forgotten how to support someone who is on an older OS, or is running older versions of a particular piece of software, you are welcome to not get involved. There's no shame in keeping current and dumping knowledge from your mind that is no longer relevant to you. :slight_smile:

The sentiments of this thread and its contents are still applicable to modern Openvpn instances. If people don't know about CRL, they should, and i hope that this is a good introduction. If someone wants to update it later with some easy-rsa v3 information that would also be fantastic.

See the OpenSSL Certificates wiki

Also, as @lantis1008 metnioned, you're running extremely dated firmware, as well as an obsolete version of OpenVPN (openvpn-openssl 2.3.6-5).

  • OpenVPN was upgraded to 2.4 quite a while back, implementing several improvements, including support for EC ciphers (which are far more efficient and less taxing to CPUs).

  • I also always recommend tuning OpenVPN server and client configs to ensure you're receiving the best throughput

Your router has 18.06 versions available

Indeed - I'd be going for 17.01.5 or 18.06 before anything else, on grounds of not wasting time with older releases when a more recent stable is available and will give good service longer into the future; whilst acknowledging lantis1008's view on tool usage itself of course.

tomsmi: Just in case you may think it's quite a job to upgrade to a new release version - upgrading OpenWRT to OpenWRT is usually far less painless than converting from Factory/Stock firmware - dramatically so on some models - don't fear it. Usually it's done before the coffee is brewed and with zero stress, no messing with buttons, no renaming of files or anything that was a pain the first time around.
At worst, you'll need to unplug the router and connect to your flash-admin machine, in case the newly flashed version conflicts with an existing IP on your network (usually

As a bystander to the thread, at least initially...

A casual user could be forgiven for believing they have the most current version when casually using a search engine...

My own search result boldy state:-

" Latest Chaos Calmer Release - OpenWrt 15.05.1
The most recent Chaos Calmer version is OpenWrt 15.05.1, the first service release of the OpenWrt 15.05 series." - source:

and a casual glance at the (incorrect/archived) "old" TOH page states 15.05.1 is the latest release for that model. (I am well aware of the reasons for the old wiki falling out of date and the merger overhead as well as sever forum problems) As a veteran OpenWRT user, the first few pages of search engine results point to old wiki pages I've bookmarked over the years. The first occurence of occurs on my third page of results :frowning:

Combine that with opkg list-upgradable showing no updates and it's understandable the casual user would assume everything was fine and nothing newer was available.

Thinking aloud to myself here:-

First: an important concept to put across to users is that it's vital to re-flash to perform the equivalent of an OS upgrade, compared using a desktop or server distro Linux package manager to do so (albeit usually in a "special", one-off way) for upgrades to a major OS version.

Second: clarify the status of each release in unambiguous terms on the main page of the project

Third: make the old TOH wiki "archive only" warning appear several times throughout each page to increase the impact of it.

Fourth: make the warnings on the old TOH wiki include a link to the device on the new wiki, to make it fast and easy.

Fifth: ensure new TOH page warning always link to the latest supported stable images automagically.

Sixth: find hundreds of people with the time to implement all the above while doing eveything else too :slight_smile:

In the case of the OP, there are no hardware reasons (eg: 4/32 issues) that prevent a more recent release, and I'd strongly recommend it for reasons of general improvements alone. Fiddling with an old version could be false economy, though I bitterly understand the mantra of "never touch a running system" :slight_smile:

Personally, I spend 99% of my time on the hardware pages of the old TOH, simply due to the prevalence of low-level hardware information and PCB photos on there. As a longterm user though, I instinctively know what to ignore if it's out of date.

Ironically, in the time I''ve spent on this reply to the thread I could have knuckled down and clarifieded the Wiki a little :confused:

The only difference between the old wiki site is the site address itself... the content is not different, unless the page has been updated since the site move. All that was done was a page/link move.

  • No one should be relying on any wiki or ToH from the old site, as no pages are updatable and the only site that will contain the most up to date information is the new wiki and new ToH sites

There has been not much change in this regard, the devicepages have been copied over to the new wiki, and since then I have cleaned up a little and added datatables showing support, hardware highlights and downloads, but pictures should be unchanged (except for some resizing perhaps).

For further discussion, please open a new topic, since we are already drifting offtopic.

I do agree that I should be moving to most recent versions of OS instead of forcing myself to use so old software despite it's security vulnerabilities. Even having just one port exposed to the world is not a reasonable setting. Bu this is also true, that loking several times thorugh OpenWRT searches i always ended on old wiki pages with Chaos Calmer listed as newest software. I'll do OS upgrade as soon as possible. Thank you for your support.

Thank, you for help in this matter even when user comse with so century-old poblem :slight_smile:

Thank you fot those links!

I totally agree - "sunday" users may have problems finding recent information. I know that cleaning up things is hard work, but luckily for me LEDE forum is full of helpful people. Thanks!

Wikis are not auto-updated and require members of the community to maintain them... i.e. if users with an arbitrary device are not regularly maintaining their device wiki, it's not going to update itself automatically.

  • Due to this, I always recommend checking out the Old Revisions [right hand side with an icon of a clock] of the page to discern the last time it was updated and what specific updates were done.