I have recently setup a SSL certificate to my domain. Installation was successful. Post installation when i opened https it showed a Internal Server error'The server encountered an internal error or misconfiguration and was unable to complete your request.' at the same time when i opened http it worked fine.
Then i have made a change in my htaccess file adding
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</ifModule>
to it. Now http is redirected to https but still am getting same Internal server error.
I checked my error log i found error
[warn] RSA server certificate CommonName (CN) `www.dimain.com' does NOT match server name!?
Please help me how to solve this.
Thanks.
May I suggest also using HTTP Strict Transport Security (HSTS) in addition to the other suggestions... :-)
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
From https://drupal.org/https-information:
Drupal configuration
If you want to support mixed-mode HTTPS and HTTP sessions open up sites/default/settings.php and add $conf['https'] = TRUE;. This enables you use the same session over HTTP and HTTPS both -- but with two cookies where the HTTPS cookie is sent over HTTPS only. You will need to use contributed modules like securepages to do anything useful with this mode, like submitting forms over HTTPS and so on. While your HTTP cookie is still vulnerable to all usual attacks, a hijacked insecure session cookie can only be used to gain authenticated access to the HTTP site. It will not be valid on the HTTPS site. Whether this is a problem or not depends on the needs of your site and the various module configurations. For example, if all forms are set to go through HTTPS and your visitors can see the same information as logged in users then this is not a problem.
For even better security, leave $conf['https'] at the default value (FALSE) and send all authenticated traffic through HTTPS and use HTTP for anonymous sessions. Once again contributed modules like 443 Session or Secure Login can help you here. Drupal 7 automatically enables the session.cookie_secure PHP configuration on HTTPS sites, which causes SSL-only secure session cookies to be issued to the browser.
For best-possible security, setup your site to only use HTTPS, not even responding to HTTP with a redirect. HTTPS is vulnerable to man-in-the-middle attacks if the connection starts out as a HTTP connection before being redirected to HTTPS. $conf['https'] can be left at its default value (FALSE) on pure-HTTPS sites. You can run the HTTP site from a different server and simply deliver a plain text message telling your users to use HTTPS.
It's a problem with your certificate not with your redirection or drupal.
Perhaps your certificate it's for yourdomaine.com and you try to access www.yourdomaine.com . If you want to access both you will need a wildcard certificate.
Related
We want to ensure all sites hosted on apache web server all protected using htpasswd (Apache Basic Authentication)
There are a few sites which are redirected from http to https, and the above authentication goes into a redirect loop on HTTPS (on further,related reading it seems that HTTP basic authentication compares the password (encrypted) format in plain text)
We have tried several samples/snippets to make basic authentication prompt work on HTTPS, but every code snippet results into multiple redirect loop and back to Auth prompt even when I key the correct password.
The links that I have already referred are : Apache .htaccess redirect to HTTPS before asking for user authentication
https://webmasters.stackexchange.com/questions/8853/properly-force-ssl-with-htaccess-no-double-authentication
Do HTTP authentication over HTTPS with URL rewriting
We have tried all the combinations SSLRequireSSL, writing it in other VirtualHost, but nothing seems to work as site redirects from HTTP to HTTPS during the Authentication, Furthermore, there are no error logs of any kind, so it implies the .htaccess and apache config is fine.
SSL,rewrite,auth etc modules are already enabled on the server
I enabled Use HTTPS for logins in HTTP Security. It works fine when I enter root address (mymoodlewebsite.com). Unfortunately it is possible to login through unsecured connection in two cases:
When session expires - Moodle asks for credentials via http login page (http:// (...) /login/index.php)
It is possible to change protocol in address bar from https to http.
After login communication is not encrypted (It should be this way).
I use Debian/Apache server.
What should I do to eliminate possibility of insecure login?
Maybe you could resolve this problem by using an Apache redirect. Create a file in login folder and name it .htaccess, then insert these lines:
# HTTP 301 redirect
RewriteEngine On
RedirectMatch 301 ^/login/login\.php$ https://%{HTTP_HOST}/login/login.php
You must have the rewrite module enabled, otherwise this solution won't work.
add this code in your moodle/config.php file
$CFG->loginhttps=false;
I have an apache server with multiple named hosts all working fine for port 80 http traffic.
(A VPS with one unique IP address)
I have one domain that has a SSL certificate and that domain is configured to handle both http and https traffic.
However if someone accidentally adds https to the beginning of a none SSL configured URL I get a typical certificate warning error (expected) and then if the user accepts the error (depending on the browser) it displays the SSL site I have configured instead of the original non-ssl domain.
I've read up a bit about SNI, but I don't have certificates for each of the other domains and would rather the server either not respond to the SSL request on anything else but one specific domain or redirect to the http version of the site.
Suggestions please as to how I approach this.
Kind regards, Spencer
For security reasons, what you're trying to achieve cannot work.
The browser (which implements the mechanisms to check the certificate) cannot know whether the user typed https:// instead of http:// accidentally or intentionally. Since it's ultimately up to the users to check that https:// is used when they think it's required, browsers should simply perform the actions requested by the users.
A redirection from https:// to http:// should always start with a valid https:// connection. SNI won't help you much there if you can't have valid certificates for the initial connection.
Otherwise, it would be fair for browsers to assume there may be a MITM attack in progress. Typing in https:// explicitly (or using HSTS) is the only reliably mechanism against MITM tools like SSLstrip, which would otherwise be capable of downgrading (or preventing an upgrade from http:// to https://).
I have installed ssl certificates on my site but the browsers still showing unsafe connection. However i can access a safe connection by using https:// before site url
If you want to force https you'll need to set that up.
As explained on the apache wiki the recommended method is to setup the http virtual host to redirect to the https virtual host. Alternatively, you can use mod_rewrite to redirect from http to https.
I'm using .htaccess to protect a website at http://www.domain.com. Secure pages redirect to https://www.domain.com, and get the apache login prompt again.
How can we have only 1 apache login prompt for both http and https?
Thank you very much.
You can't. As far as the browser is concerned, http: and https: are two different websites, and you won't get it to tell the https: site which password the user entered for the http: site. Doing so would be a serious security bug in general, and the HTTP authentication protocol is not advanced enough to allow the http: server to tell the browser, "it is OK to repeat this password for such-and-such site". (And why would you trust a security exception given to you by a mere http: site anyway?)
Why don't you just do everything over https?
Or, put differently, why do you do anything that requires authentication over plain HTTP? That's not very secure. And if you have something on the https site that deserves https security, an attacker could just sniff the passwords from the insecure http connections.