Hello,
Knowing that VPN Red is deprecated OpenVPN is still my only option to use at the moment. Upon setting up the connection accoring to https://riseup.net/en/vpn/vpn-red my client is not able to connect due to a certificate format error (regardless of the TLS version defined in the client config):
...
Nov 6 15:29:22 openvpn[24586]: TLS Error: TLS handshake failed
Nov 6 15:29:22 openvpn[24586]: TLS Error: TLS object -> incoming plaintext read error
Nov 6 15:29:22 openvpn[24586]: TLS_ERROR: BIO read tls_read_plaintext error
Nov 6 15:29:22 openvpn[24586]: OpenSSL: error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed
Nov 6 15:29:22 openvpn[24586]: VERIFY ERROR: depth=1, error=format error in certificate's notBefore field: CN=Riseup Networks, O=Riseup Networks, L=Seattle, ST=WA, C=US, emailAddress=collective@riseup.net
Nov 6 15:29:22 openvpn[24586]: VERIFY ERROR: depth=1, error=format error in certificate's notBefore field: CN=Riseup Networks, O=Riseup Networks, L=Seattle, ST=WA, C=US, emailAddress=collective@riseup.net
Nov 6 15:29:22 openvpn[24586]: VERIFY ERROR: depth=1, error=format error in certificate's notBefore field: CN=Riseup Networks, O=Riseup Networks, L=Seattle, ST=WA, C=US, emailAddress=collective@riseup.net
...
Is this something that you guys are aware of or can/would be fixed at all (knowing VPN Red is deprecated)?
Cheers,
Istvan
Hi,
I'm not sure what to tell you, to be honest. The certificate is valid, and a number of users are using the VPN. I suspect that this is a libressl bug with certificate parsing. Maybe this is the issue on their side: https://github.com/libressl-portable/portable/issues/472
I'm not sure what to tell you, to be honest. The certificate is valid, and a number of users are using the VPN. I suspect that this is a libressl bug with certificate parsing. Maybe this is the issue on their side: https://github.com/libressl-portable/portable/issues/472
Hi,
Thank you for the reply! It indeed seems to be a LibreSSL issue (I have just reinstalled most of the router linked against OpenSSL and that way it works straight away). Interesting, at the github issue report (cheers for the link!) it is said to be fixed a longer time ago, but still it is still here with me. :(
The interesting thing is that this is my first time seeing this error though I'm using other VPNs and encrypted things as well. Anyway it works with OpenSSL, and that's what matters.
Cheers!
Thank you for the reply! It indeed seems to be a LibreSSL issue (I have just reinstalled most of the router linked against OpenSSL and that way it works straight away). Interesting, at the github issue report (cheers for the link!) it is said to be fixed a longer time ago, but still it is still here with me. :(
The interesting thing is that this is my first time seeing this error though I'm using other VPNs and encrypted things as well. Anyway it works with OpenSSL, and that's what matters.
Cheers!
Great, thanks for getting back to us with what you found. If you find out more info, please do let us know.
I'll close this issue for now, but if you reply, it will re-open it.
I'll close this issue for now, but if you reply, it will re-open it.
Hello again,
I think I managed to find the real issue here. Actually LibreSSL is more or less correct as per RFC5280 (though it should really be more tolerant) in this case and OpenSSL just works because of compatibility. https://riseup.net/security/network-security/riseup-ca/RiseupCA.pem is not conformant to RFC5280 as it indeed uses GeneralizedTime instead of UTCTime (I believe it means that it stores only the last two digits of the year in question):
"CAs conforming to this profile MUST always encode certificate
validity dates through the year 2049 as UTCTime; certificate validity
dates in 2050 or later MUST be encoded as GeneralizedTime.
Conforming applications MUST be able to process validity dates that
are encoded in either UTCTime or GeneralizedTime."
I think I managed to find the real issue here. Actually LibreSSL is more or less correct as per RFC5280 (though it should really be more tolerant) in this case and OpenSSL just works because of compatibility. https://riseup.net/security/network-security/riseup-ca/RiseupCA.pem is not conformant to RFC5280 as it indeed uses GeneralizedTime instead of UTCTime (I believe it means that it stores only the last two digits of the year in question):
"CAs conforming to this profile MUST always encode certificate
validity dates through the year 2049 as UTCTime; certificate validity
dates in 2050 or later MUST be encoded as GeneralizedTime.
Conforming applications MUST be able to process validity dates that
are encoded in either UTCTime or GeneralizedTime."
Hi again,
Thanks for the research into the RFC, but I'll have to disagree with you, if I look at the certificate with gnutls' certtool, I see the date represented as UTC time:
Validity:
Not Before: Sat Jan 02 20:25:40 UTC 2016
Not After: Mon Mar 30 20:26:01 UTC 2026
This seems to conform to RFC5280's requirement, since it is before the year 2050 it should be represented as UTC time.
Thanks for the research into the RFC, but I'll have to disagree with you, if I look at the certificate with gnutls' certtool, I see the date represented as UTC time:
Validity:
Not Before: Sat Jan 02 20:25:40 UTC 2016
Not After: Mon Mar 30 20:26:01 UTC 2026
This seems to conform to RFC5280's requirement, since it is before the year 2050 it should be represented as UTC time.
Hi Crossbill,
Thank you for getting back on this. Indeed you are right, it must be an issue with LibreSSL then (I don't yet see where though).
Btw the output of openssl at my end of the Riseup certificate is:
notBefore=Jan 2 20:25:40 2016 GMT
notAfter=Mar 30 20:26:01 2026 GMT
While the same output of a known working certificate is:
notBefore=Feb 15 14:38:00 2017 GMT
notAfter=Feb 15 14:38:00 2027 GMT
Which seems fairly identical unless openssl (and certtool) hides something.
Thanks for your help, I'll carry on researching then. :)
Thank you for getting back on this. Indeed you are right, it must be an issue with LibreSSL then (I don't yet see where though).
Btw the output of openssl at my end of the Riseup certificate is:
notBefore=Jan 2 20:25:40 2016 GMT
notAfter=Mar 30 20:26:01 2026 GMT
While the same output of a known working certificate is:
notBefore=Feb 15 14:38:00 2017 GMT
notAfter=Feb 15 14:38:00 2027 GMT
Which seems fairly identical unless openssl (and certtool) hides something.
Thanks for your help, I'll carry on researching then. :)
Hi Crossbill,
I think certtool is cheating here! :) (or at least means a different thing with UTC than us)
According to 'openssl asn1parse -in RiseupCA.pem' the certificate time is indeed GenerializedTime:
...
175:d=2 hl=2 l= 34 cons: SEQUENCE
177:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20160102202540Z
194:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20260330202601Z
211:d=2 hl=3 l= 134 cons: SEQUENCE
...
This might be the problem with LibreSSL then.
I think certtool is cheating here! :) (or at least means a different thing with UTC than us)
According to 'openssl asn1parse -in RiseupCA.pem' the certificate time is indeed GenerializedTime:
...
175:d=2 hl=2 l= 34 cons: SEQUENCE
177:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20160102202540Z
194:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20260330202601Z
211:d=2 hl=3 l= 134 cons: SEQUENCE
...
This might be the problem with LibreSSL then.
If you look at the DER encoded version of the certificate, by sending it through 'hd', you will see the time specification is done in Zulu time:
20160102202540Z..20260330202601Z
However, I need to look at the actual ASN.1 says about it, because if it is UTC or Generalized it is not open for interpretation, and that looks like it is saying it is GeneralizedTime
20160102202540Z..20260330202601Z
However, I need to look at the actual ASN.1 says about it, because if it is UTC or Generalized it is not open for interpretation, and that looks like it is saying it is GeneralizedTime
Ok, so reading carefully the RFC, the third "MUST" in that paragraph says this:
Conforming applications MUST be able to process validity dates that are encoded in either UTCTime or GeneralizedTime.
i'm pretty sure that "process" means "interpret legitimately", so if the CA MUST encode validity dates through the year 2049 as UTCTime, then the cert was incorrectly generated, and because libressl doesn't "interpret legitimately" an incorrectly specified date, it is also doing the wrong thing.
Conforming applications MUST be able to process validity dates that are encoded in either UTCTime or GeneralizedTime.
i'm pretty sure that "process" means "interpret legitimately", so if the CA MUST encode validity dates through the year 2049 as UTCTime, then the cert was incorrectly generated, and because libressl doesn't "interpret legitimately" an incorrectly specified date, it is also doing the wrong thing.
This is indeed a lot more complex than it should be. :) One source of confusion is that as far as I gather after reading through forums and whatnot Zulu time, UTC and GMT are used interchangably meaning only the timezone not the format.
To further complicate matters the RFC is pretty vague and contradictory in my opinion in this time format regard, but my conclusion is as yours: neither the CA nor LibreSSL are compliant to this RFC.
I have filed a bug report to LibreSSL about this, hopefully it will get fixed.
On the other hand please create the next CA with UTCTime format when the current one expires in 2026.
Thanks for your help and patience! :)
To further complicate matters the RFC is pretty vague and contradictory in my opinion in this time format regard, but my conclusion is as yours: neither the CA nor LibreSSL are compliant to this RFC.
I have filed a bug report to LibreSSL about this, hopefully it will get fixed.
On the other hand please create the next CA with UTCTime format when the current one expires in 2026.
Thanks for your help and patience! :)
Yeah, I had the same thinking as you, the timezone pieces are confusing and the RFC is vague!
If it were easy, I'd get the CA re-issued, but it would require that everyone download the new one, and be quite disruptive.
anyways, thanks for digging into this!
If it were easy, I'd get the CA re-issued, but it would require that everyone download the new one, and be quite disruptive.
anyways, thanks for digging into this!