Tag Info

New answers tagged

0

If the browsers would do proper OCSP checking, e.g. connect only to sites where they got a proper OCSP response (e.g. a signed yes or no, not a try later) it would be secure enough. But browsers don't, e.g. they mostly accept try later responses, except for extended validation certificates. If servers would all support OCSP stapling there would be not ...


-1

Whilst using the CRLSet feature in Chrome is supposed to offer better performance, how does performance replace the security of users if there is no certainty of actual trust? Point in case was recently the CloudFlare challenge website which revoked it's certificate. I decided to test my main two browsers to make sure I still wasn't being taken to the ...


0

Turns out the problem had nothing to do with the certificate and everything to do with the fact that the client was coming in over the VPN. When the client was physically on the network, everything worked fine. I ended up having to change the MTU on the ubuntu server and everything worked fine.


4

I'm the maintainer of HTTPS Everywhere and just merged a pull request fixing this issue. It should be in the next release (out in 1-2 weeks). For future reference, submitting these to Github means they'll get fixed sooner :). (https://github.com/efforg/https-everywhere)


1

the common name cannot be an IP address. You may put IP addresses into the subject alternative name section, but as IP address not DNS the certificate might need a CA=true property if you want to import it as authority, simply self-signing might not be enough. You might still be able to import it and it will show up, but does not work. it failed for me for ...



Top 50 recent answers are included