Concerns for distribution of CA cert

Freewheeling spot to chew the fat on anything cryptostorm-related that doesn't fit elsewhere (i.e. support, howto, &c.). Criticism & praise & brainstorming & requests for explanation... this is where it goes when it's hot & ready for action! :-)
Posts: 8
Joined: Mon Jul 24, 2017 2:47 am

Concerns for distribution of CA cert

Post by maltfield » Sun Dec 24, 2017 9:06 pm


I think the distribution of the recent CA cert change could have been greatly improved by cryptographically signing the replacement cert in a way that can be verified out-of-band.

Correct me if I'm wrong, but this single file is absolutely crucial to obtaining confidentiality when using the cryptstorm vpn service.

* ... ter/ca.crt

If someone was able to modify the contents of this ca.txt file while I'm downloading its new version, they would be able to effectively man-in-the-middle all of my traffic to cryptostorm. After doing so, they could see all the sites I visited and all of the contents of my traffic that isn't end-to-end encrypted (lest the MITM those connections too!).

The official notice that advertised this change of CA is here:


The contents of this message was sadly very terse:
The CA certificate our OpenVPN setup uses is set to expire on Dec 22, so we've had to generate new ones.
That means by Dec 22, all members need to be using the latest one.

The configuration files at GitHub have already been updated with the new CA.

If you want to modify your existing configs manually, you can get the latest CA from

If you are using v2.22 or v3.0 of the widget, you'll need to upgrade to the new v3.1 widget at (hashes available here)
Due to a bug in the self-updating code in v3.0, the widget will NOT automatically upgrade to v3.1. You'll have to manually download/install it from the above link.
If you're still using v2.22, the updating code there will still work since that version just did a simple `start`, and setup.exe there has been updated to v3.1.
v3.1 of the widget is using the latest OpenVPN 2.4.x, which means XP is no longer supported.
If you require XP for some reason, you can use an older version of OpenVPN GUI to connect, although even that will most likely stop being supported in the near future.

Note: You can still connect using the old CA certificate, but after Dec 22 OpenVPN will show a fatal error that the CA certificate you're using has expired.
Nothing in the above message mentioned any way to verify the integrity of the new file out-of-band! Therefore, if someone was MITM'ing the TLS connection between the client & (which is trivial for many powerful multinational corporations & state actors that own CAs whitelisted by our browsers), they'd be able to arbitrarily hand me any contents of the 'ca.txt' file, and then intercept all my future traffic with cryptostorm over my vpn connection.

My proposal is:

add a <pre></pre> block on the page '' with an clearsigned pgp message. The signed message should
  1. state the reason for the change
  2. include the new cert and
  3. describe how to validate the authenticity & integrity of the new key
Obviously the cryptstorm team recognizes the risks of authentication within the X.509 PKI trust model. This is why the certificate is pinned when connecting to crytostorm--it prevents the risk of a man-in-the-middle injecting their own CA. However, releasing an updated version of that pinned CA for clients to download over the same untrusted X.509 trust model (especially when doesn't even use HSTS or HPKP!) is a huge security risk.

Code: Select all

user@personal:~$ curl -i 
HTTP/1.1 200 OK
Date: Sun, 24 Dec 2017 16:03:42 GMT
Server: Apache
x-frame-options: SAMEORIGIN
Last-Modified: Mon, 18 Dec 2017 07:24:22 GMT
Accept-Ranges: bytes
Content-Length: 1866
Content-Type: text/plain

Does there exist any way to currently validate the authenticity & integrity of the newly distributed CA cert out-of-band? If not, what are your thoughts on implementing the above-suggested solution?


User avatar
Site Admin
Posts: 495
Joined: Thu Jan 01, 1970 5:00 am

Re: Concerns for distribution of CA cert

Post by df » Wed Dec 27, 2017 3:19 pm

The new CA certificate was signed using the same private key that the old certificate was signed with, in a way that allowed us to accept clients using either the old or new CA certificate. That is, until Dec 22 came around, causing a fatal error for anyone still using the old certificate.

That means the modulus and exponent stays the same for the old or new CA certificate:

Code: Select all

[root@b ~]# openssl x509 -noout -modulus -in oldca.crt;openssl x509 -noout -text -in oldca.crt|grep Exp
                Exponent: 65537 (0x10001)

Code: Select all

[root@b ~]# openssl x509 -noout -modulus -in newca.crt;openssl x509 -noout -text -in newca.crt|grep Exp
                Exponent: 65537 (0x10001)
That should be enough verification for anyone concerned with MiTM. Without access to our CA private key, an attacker wouldn't be able to generate their own CA certificate that has the same modulus and exponent as either of our certificates.

See and/or ... h-openssl/ for more info