Since our issuance of new server-side certificate materials after the 'heartbleed' vuln was publicly disclosed, there's occasions when members with old configuration files (or folks who find old materials archived or cached on third-party sites and attempt unknowingly to use these) occasionally need to find our "new" certificate materials in order to successfully connect to cryptostorm.
These materials are embedded in every current (rev. 1.3 or higher) "conf" file we provide, as well as in all current builds of our client widget. However, for convenience, we're posting that cert material here in the event folks have a need to access it without hassle:
Code: Select all
-----BEGIN CERTIFICATE----- MIIFHjCCBAagAwIBAgIJAKekpGXxXvhbMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTE0MDQyNTE3 MTAxNVoXDTE3MTIyMjE3MTAxNVowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDJaOSYIX/sm+4/OkCgyAPYB/VPjDo9YBc+zznKGxd1F8fAkeqcuPpGNCxMBLOu mLsBdxLdR2sppK8cu9kYx6g+fBUQtShoOj84Q6+n6F4DqbjsHlLwUy0ulkeQWk1v vKKkpBViGVFsZ5ODdZ6caJ2UY2C41OACTQdblCqaebsLQvp/VGKTWdh9UsGQ3LaS Tcxt0PskqpGiWEUeOGG3mKE0KWyvxt6Ox9is9QbDXJOYdklQaPX9yUuII03Gj3xm +vi6q2vzD5VymOeTMyky7Geatbd2U459Lwzu/g+8V6EQl8qvWrXESX/ZXZvNG8QA cOXU4ktNBOoZtws6TzknpQF3AgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUOFjh918z L4vR8x1q3vkp6npwUSUwge8GA1UdIwSB5zCB5IAUOFjh918zL4vR8x1q3vkp6npw USWhgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5 cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv cm0uaXOCCQCnpKRl8V74WzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB AQAK6B7AOEqbaYjXoyhXeWK1NjpcCLCuRcwhMSvf+gVfrcMsJ5ySTHg5iR1/LFay IEGFsOFEpoNkY4H5UqLnBByzFp55nYwqJUmLqa/nfIc0vfiXL5rFZLao0npLrTr/ inF/hecIghLGVDeVcC24uIdgfMr3Z/EXSpUxvFLGE7ELlsnmpYBxm0rf7s9S9wtH o6PjBpb9iurF7KxDjoXsIgHmYAEnI4+rrArQqn7ny4vgvXE1xfAkFPWR8Ty1ZlxZ gEyypTkIWhphdHLSdifoOqo83snmCObHgyHG2zo4njXGExQhxS1ywPvZJRt7fhjn X03mQP3ssBs2YRNR5hR5cMdC -----END CERTIFICATE-----
If you're curious about what this block of gibberish is, and why it's part of connecting to cryptostorm, this short overview explains the procedural side of things. In a nutshell, this bit of text helps verify that the "server" to which you are connecting during a cryptostorm session is actually one controlled and managed by cryptostorm, and not an imposter posing as cryptostorm (these attacks are broadly known as "Man in the Middle" attacks; or MiTM). This text, via a cryptographically strong method, acts as a sort of 'fingerprint" of a private key held only on cryptostorm's servers and carefully protected from outside access (the risk such keys were accessed as a result of the 'heartbleed' bug mentioned above is why we re-issued new certificates - and new private keys - on all our servers earlier this year): only someone with the private key can prove that they have that key, and they need not do so by actually showing the key itself but rather by a process of "public key cryptography" that allows for this kind of "prove but don't publish" validation.
In this step of the process of connecting to cryptostorm and exchanging data securely, public key cryptography is actually not being used to encrypt any data. Rather, this is solely a means of validating server identity; it uses the same maths as public key crypto that encrypts data (actually, it encrypts transient symmetric keys that then, themselves, are used to encrypt data... but we digress), but instead is using that math to confirm the server is genuine. Here's a snippet from a well-written Mozilla foundation site explaining SSL, PKI, public key crypto, and how it all interconnects in both theory and practice:
Cryptostom's use of PKI infrastructure during session initiation with members is different from that used in "default" openvpn installations. We have removed the elements relating to PKI verification of client identity. Those curious about why we feel this provides important security benefits for our network members will find a more detailed explanation of the analysis in our intro to token-based auth; this paper explores the assumptions implicit in naive, bidirectional PKI-based "VPN service" authentication models, and outlines why we feel these assumptions are counterproductive to member security in our production environment. Occasionally, members or outside observers conclude that we "don't understand cryptography" because we haven't blindly followed the instructions for default openvpn installations. We hope that a review of the token auth paper will dispel the sense that we've simply "not read the manual," although simply doing something different from default is not in and of itself an assurance that our approach is better. To make that conclusion, our analytic framework must hold up under both logical and practical scrutiny."SSL requires a server SSL certificate, at a minimum. As part of the initial "handshake" process, the server presents its certificate to the client to authenticate the server's identity. The authentication process uses public-key encryption and digital signatures to confirm that the server is in fact the server it claims to be.
If there are any questions or requests for additional explanation, please do not hesitate to post them in this thread.