Tag Info

New answers tagged

1

Here are some of the broad brushstroke issues: MITM/SSLSTRIP: This is a huge caveat. If you're going to serve your site over HTTPS, then disable HTTP on the site. Otherwise, you leave your users open to various man-in-the-middle attacks including SSLSTRIP, which will intercept requests and quietly serve them over HTTP, inserting their own malware script ...


2

The question mark signifies the end of the path portion of the uri and the beginning of the query string. Hence why nginx will not return 404 based on the portion after the question mark; the requested resource does exist and the query string parameters are just passed to it. Regarding the other part of the question, I believe that nginx's rewrite statement ...


5

With some providers of SSL certificates (Digicert as one) you can generate new private keys and CSRs to request certificates on each server. This allows you to maintain separate private keys (and also generate these certificates for subdomains using Subject Alternative Names.). This does increase the administrative burden, but decreases the risk of sharing a ...


4

This is not possible. You either need self-signed certificates or you need individual certificates.


2

You never need to add additional IP addresses to the local host on any operating system (Unix like, Windows, whatever). They will all respond by default, without additional configuration, to all IP addresses from 127.0.0.0/8: $ ping 127.254.0.100 PING 127.254.0.100 (127.254.0.100) 56(84) bytes of data. 64 bytes from 127.254.0.100: icmp_seq=1 ttl=64 ...


0

The problem was in the frontend syntax. I had to change: proxy_pass http://mybackend:8081/git$1; to the correct: proxy_pass http://mybackend:8081/git$1$is_args$args; or alternatively: proxy_pass http://mybackend:8081$request_uri; Thanks, Will!


0

If you access your site by name localhost and when your SSL certificate is configured to a hostname (or some other name), your client may refuse to connect to it. It is difficult to say how to fix the problem without knowing the specifics, but you can either try making your requests with the same name that is in the SSL certificate or try turning off client ...


1

Users will still get a warning screen if they go to a https site that redirects - the redirect happens after the warning, not prior. Chances are you've just accepted the warning already. Google will eventually re-index and use the http versions, but until then your best option is to pay the $7 bucks or so for a valid SSL.


0

First, which type of application are you using? If it's a webservice or similar, you could indeed use HTTPS. Configure your webservice that it only accepts https connections and provice a .htaccess file with authentication. The HTTPS prevents people from sniffing your credentials. The .htaccess prevents unauthorized users to get access. In case it's not a ...


0

Quite simply not possible. Authenticating would involve reading what the user says. Passing the original certificates from the original issue makes this impossible. This is the entire purpose of HTTPS


28

Look closely at the certificate: X509v3 Subject Alternative Name: DNS:*.googleusercontent.com, DNS:*.blogspot.com, DNS:*.bp.blogspot.com, DNS:*.commondatastorage.googleapis.com, DNS:*.doubleclickusercontent.com, DNS:*.ggpht.com, DNS:*.googledrive.com, DNS:*.googlesyndication.com, DNS:*.storage.googleapis.com, DNS:blogspot.com, DNS:bp.blogspot.com, ...



Top 50 recent answers are included