6 ms·

Strangely, on my computer, Firefox reports a security error on the site. No error in Chrome. An error occurred during a connection to golang.org. secur

by Rexxar 11y ago

Strangely, on my computer, Firefox reports a security error on the site. No error in Chrome. An error occurred during a connection to golang.org. security library: DER encoded incorrectly formatted message. (Error code: sec_error_bad_der) I didn't have this the last time I went on golang.org.

lukevers 11y ago
Same here. If you go to the link without ssl it'll load for you though.
- httpseverywhere 11y ago
  HTTPS Everywhere is the bane of my crap-configured-ssl-server existence :(.
  - tyho 11y ago
    Click on the icon in the menu bar. It allows you to disable the rules for domains where it is broken.
stygiansonic 11y ago
The certificate for golang.org was recently (re)issued. I see a "Not Valid Before" of "Thursday, May 21, 2015 at 5:39:30 AM Eastern Daylight Time". I wonder if there is a Firefox-unsupported certificate extension in the new certificate? EDIT: I wonder if it's related to this Firefox issue: Secure connection failed (sec_error_bad_der) due to certs with SAN dNSName entries incorrectly containing IP addresses[0] However, it doesn't appear the golang.org certificate has any subjectAltName DNS entries using an IP address. 0. https://bugzilla.mozilla.org/show_bug.cgi?id=1148766 https://bugzilla.mozilla.org/show_bug.cgi?id=1148766
- throwaway2048 11y ago
  The most frustrating part about this is when you want to access router/etc machines via https and an ip address it is just no longer even possible if they dont support this particular certificate extension. Firefox doesn't even give you a way to bypass the erorr, even the error itself gives absolutely zero indication of what the issue actually IS. It's extraordinarily obnoxious.
  - rockdoe 11y ago
    Huh? You can't put an IP into a DNS entry but you can put them into an IP entry.
    - throwaway2048 11y ago
      Yet it worked fine for 20 years beforehand and is how a lot of management interfaces are connected to and used. Now a minor bit of certificate paper work is wrong by fiat, anything relying on it is no longer allowed to work, peroid, even with a manual override. Great. I guess I'll just fork out $10k to satisfy some stupid technicality.
      - rockdoe 11y ago
        Your argument could be used against pretty much any of the tightenings up wrt. HTTPS certs that have been done for the last few years. "We used to be able to do whatever and be marked a secure and now we actually have to do security right! UNACCEPTABLE". Not very convincing.
  - vacri 11y ago
    Firefox doesn't even give you a way to bypass the erorr Removing the 's' from 'https' in FF works for me.
    - throwaway2048 11y ago
      and if that dosen't exist or auto redirects to https you are screwed. No matter how you slice it not even allowing an override over something like this is super shitty.
nickysielicki 11y ago
Same issue here, using firefox. openSSL doesn't complain though: sielicki@wetdog ~ $ openssl s_client -connect golang.org:443 -CApath /etc/ssl/certs CONNECTED(00000003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.appspot.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- <...> Start Time: 1432839068 Timeout : 300 (sec) Verify return code: 0 (ok) --- Makes sense, I guess... firefox/iceweasel don't look at /etc/ssl/certs, they only trust what mozilla puts out.
rockdoe 11y ago
The cert includes a wildcard for *.google, which Firefox rejects because it's a wildcard on a top level domain. I can't really tell who's right here from the specs. https://bugzilla.mozilla.org/show_bug.cgi?id=1169149 https://bugzilla.mozilla.org/show_bug.cgi?id=1169149
- stygiansonic 11y ago
  Good catch! The addition is for the new .google TLD. Looks like the Chromium source code had some "protection" against this, at least at one point in time: http://security.stackexchange.com/questions/6873/can-a-wildcard-ssl-certificate-be-issued-for-a-second-level-domain http://security.stackexchange.com/questions/6873/can-a-wildc... It appears that the specification (RFC 2818?) doesn't specify what is acceptable with regards to allowed wildcard certificates - leaving the various implementations to decide what is "too risky" for themselves.

by Rexxar 11y ago

lukevers 11y ago

Same here. If you go to the link without ssl it'll load for you though.

httpseverywhere 11y ago
HTTPS Everywhere is the bane of my crap-configured-ssl-server existence :(.
- tyho 11y ago
  Click on the icon in the menu bar. It allows you to disable the rules for domains where it is broken.

stygiansonic 11y ago

The certificate for golang.org was recently (re)issued. I see a "Not Valid Before" of "Thursday, May 21, 2015 at 5:39:30 AM Eastern Daylight Time". I wonder if there is a Firefox-unsupported certificate extension in the new certificate? EDIT: I wonder if it's related to this Firefox issue: Secure connection failed (sec_error_bad_der) due to certs with SAN dNSName entries incorrectly containing IP addresses[0] However, it doesn't appear the golang.org certificate has any subjectAltName DNS entries using an IP address. 0. https://bugzilla.mozilla.org/show_bug.cgi?id=1148766 https://bugzilla.mozilla.org/show_bug.cgi?id=1148766

throwaway2048 11y ago
The most frustrating part about this is when you want to access router/etc machines via https and an ip address it is just no longer even possible if they dont support this particular certificate extension. Firefox doesn't even give you a way to bypass the erorr, even the error itself gives absolutely zero indication of what the issue actually IS. It's extraordinarily obnoxious.
- rockdoe 11y ago
  Huh? You can't put an IP into a DNS entry but you can put them into an IP entry.
  - throwaway2048 11y ago
    Yet it worked fine for 20 years beforehand and is how a lot of management interfaces are connected to and used. Now a minor bit of certificate paper work is wrong by fiat, anything relying on it is no longer allowed to work, peroid, even with a manual override. Great. I guess I'll just fork out $10k to satisfy some stupid technicality.
    - rockdoe 11y ago
      Your argument could be used against pretty much any of the tightenings up wrt. HTTPS certs that have been done for the last few years. "We used to be able to do whatever and be marked a secure and now we actually have to do security right! UNACCEPTABLE". Not very convincing.
- vacri 11y ago
  Firefox doesn't even give you a way to bypass the erorr Removing the 's' from 'https' in FF works for me.
  - throwaway2048 11y ago
    and if that dosen't exist or auto redirects to https you are screwed. No matter how you slice it not even allowing an override over something like this is super shitty.

nickysielicki 11y ago

Same issue here, using firefox. openSSL doesn't complain though: sielicki@wetdog ~ $ openssl s_client -connect golang.org:443 -CApath /etc/ssl/certs CONNECTED(00000003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.appspot.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- <...> Start Time: 1432839068 Timeout : 300 (sec) Verify return code: 0 (ok) --- Makes sense, I guess... firefox/iceweasel don't look at /etc/ssl/certs, they only trust what mozilla puts out.

rockdoe 11y ago

The cert includes a wildcard for *.google, which Firefox rejects because it's a wildcard on a top level domain. I can't really tell who's right here from the specs. https://bugzilla.mozilla.org/show_bug.cgi?id=1169149 https://bugzilla.mozilla.org/show_bug.cgi?id=1169149

stygiansonic 11y ago
Good catch! The addition is for the new .google TLD. Looks like the Chromium source code had some "protection" against this, at least at one point in time: http://security.stackexchange.com/questions/6873/can-a-wildcard-ssl-certificate-be-issued-for-a-second-level-domain http://security.stackexchange.com/questions/6873/can-a-wildc... It appears that the specification (RFC 2818?) doesn't specify what is acceptable with regards to allowed wildcard certificates - leaving the various implementations to decide what is "too risky" for themselves.