Tag Info

Hot answers tagged

39

Please try this Chrome hack: when browser shows the page with the invalid certificate message, type in your keyboard the word "proceed" and then hit Enter. You should be able to proceed to the requested page.


24

This is a feature called HTTP Strict Transport Security - see http://dev.chromium.org/sts and http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security. Sites that send the Strict-Transport-Security header (or are preloaded in Chrome, such as apis.google.com) cannot be accessed when the server SSL cert is invalid. The certificate sent for ...


7

A certificate is only as good as whoever validates it thinks it is. A certificate is good for SSL as long as the SSL clients (e.g. Web browsers, or VPN clients) accept it as good. Whatever you do, the existing clients will lead the dance. A "wildcard" certificate is described in RFC 2818, section 3.1: Names may contain the wildcard character * ...


6

Your certificate will have certain properties, I believe they are called 'certificate usage' or similar. If, under there, you find Certificate Signing, then yes - you can use your certificate to sign other certificates. Note: the constraint Signing alone does not mean you can sign other certificates, it must be the full Certificate Signing. Your wildcard ...


4

It is not a matter of wildcards. The behaviour you observe is due to the following: if there is a Subject Alt Name extension in the certificate, then the Common Name part of the DN is simply ignored. Said otherwise, the server names in the certificate should always be in a Subject Alt Name extension; the Common Name part of the subject DN is used as a ...


2

It is not a good idea to have a public DNS record which points to a non-public IP address. This can be used to circumvent same origin policies by exploiting issues on internal systems. For more details see http://www.securityfocus.com/archive/1/486606, where a vulnerability in CUPS on localhost was exploited this way. Probably easier and definitly safer ...


2

The Server Name Indication extension, now implemented by most SSL libraries, implies that a sniffer would see the name api2.server2.com as part of the unencrypted ClientHello message from server1. As for the rest of the URL (the path on server2), it is sent only after the handshake, so it is not visible to sniffers (but sniffers may still obtain a good ...


1

I would be very surprised if you ever got a valid certificate that did both. Certificate signing certs tend to only do that, not support server identification (e.g, SSL), given how much they really need to be protected. If that certificate and private key were installed on a web server, all an attacker would have to do is breach that web server, and they ...



Only top voted, non community-wiki answers of a minimum length are eligible