SSLVerifyClient not asking for certificate - apache

When I put the directives:
SSLVerifyClient require
SSLVerifyDepth 2
SSLCertificateFile cert/path/cert.crt
Inside a virtual host directive and then go to the website a pop up box does not ask for my certificate. However when I put the same directives before the virtual host it will.
Why does it act this way?
The documentation actually says the SSL directives listed should be defined inside the virtual host.

Related

MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT HSTS in https site

I downloaded a project on localhost via bitbucket, I set up a virtual host but I have an error on each browser that the certificate is self-signed. I created the certificate in xampp and added it to trusted certificates in the chrome / windows 10 settings and unfortunately I still have the same error.
The project is on laravel 5 and in env file, I set the http and APP_DEV domain to local.
My virtual host:
<VirtualHost *:443>
DocumentRoot "E:\xampp\htdocs\project\public"
ServerName project.app
SSLEngine On
SSLCertificateFile "E:/xampp/apache/conf/ssl.crt/server.crt"
SSLCertificateKeyFile "E:/xampp/apache/conf/ssl.key/server.key"
<Directory "E:\xampp\htdocs\project\public">
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
I would like to run a project via virtual host on laravel 5. Unfortunately, I still have the error HSTS MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT on Firefox, and NET :: ERR_CERT_COMMON_NAME_INVALID on Chrome.
I will add that I only want to run the project locally on the localhost, therefore no certificate is needed here, but the browser blocks
This error related to .app, .dev TLD.Chromium forced all domains with the .app,.dev TLD to only respond to secure connections

How to set up SSL for localhost and virtual hosts with MAMP?

I'm creating this "question" to document how I was able to set up SSL locally, in case I need to do this again in the future. Thought I'd document it here hoping this can be of help to others too, 'cause it's a tricky process.
I'm working on a Mac with High Sierra, MAMP v 4.2.1 and Chrome v 71
Alright, let's roll.
1) Create a SSL certificate for localhost
To be able to use HTTPS with localhost we actually need two certificates: a root certificate, and a domain certificate specifically created for the localhost domain.
These nifty scripts I've found take care of creating both. They're very easy to use—just follow the instructions closely and you'll be good to go. The only thing that is not so clear in the documentation is that, where it says Then mark the certificate as trusted, this means you have to click on the certificate in Keychain Access and change the Trust option to Always.
(Here you can find a more elaborate explanation of what those scripts actually do)
If everything worked for you, you should now have two files server.crt and server.key. I've created a ssl folder in /Applications/MAMP and moved the files in it; but you can put them wherever you think is best.
Let's forget about the files now and proceed to some Apache configuration.
2) Configure MAMP's Apache to accept SSL
By default, Apache is not configured to accept SSL connections, so we have to change that. Open /Applications/MAMP/conf/apache/httpd.conf and make sure the following lines are NOT commented out. If they are, remove the # at the beginning of the line:
LoadModule ssl_module modules/mod_ssl.so
Include /Applications/MAMP/conf/apache/extra/httpd-ssl.conf
Also, look for this line:
Servername localhost:443
and make sure the port is set to 443. 443 is the default port for HTTPS secured connections (regular, unsecured HTTP connections listen to port 80 by default).
Next, open /Applications/MAMP/conf/apache/extra/httpd-ssl.conf and make sure you have this line:
Listen 443
Again, this is important because we have to set up everything on the same port. To this end, you should also click on the MAMP icon in your MAC's dock, hit Preferences, go to the Ports tab and choose Set Web & MySql ports to 80 & 3306.
Stop and restart MAMP to apply the changes we've made so far.
3) Configure the default Virtual Host for SSL
While still in /Applications/MAMP/conf/apache/httpd.conf, look for these lines:
<VirtualHost _default_:443>
# General setup for the virtual host
DocumentRoot "/Applications/MAMP/Library/htdocs"
ServerName www.example.com:443
These lines set Apache's default behavior for all HTTPS connections. The ServerName is just a dummy name that you should replace with localhost; you should also make sure that the default DocumentRoot does match with your projects root folder.
So change the above lines as follows:
<VirtualHost _default_:443>
# General setup for the virtual host
DocumentRoot "/path/to/your/htdocs"
ServerName localhost
As you scroll a bit further down, while we're still in the default VirtualHost directive, you will find these two lines:
SSLCertificateFile "/Applications/MAMP/conf/apache/server.crt"
SSLCertificateKeyFile "/Applications/MAMP/conf/apache/server.key"
Change these to wherever you put the files we genereated in step 1. Like I said before, I've put mine in "/Applications/MAMP/ssl", so I've changed the
above lines to:
SSLCertificateFile "/Applications/MAMP/ssl/server.crt"
SSLCertificateKeyFile "/Applications/MAMP/ssl/server.key"
Stop and restart MAMP to apply the changes. Now if you go to https://localhost you should be able to see the list of projects in your root folder. That's it for localhost!
4) Create a SSL certificate for custom local domains
What if you wanted to create a custom domain myproject.dev and use SSL for that too, so you could access it at https://myproject.dev?
Pretty much like what we did for localhost, we need to create a SSL certificate specifically for the myproject.dev domain, then configure a virtual host for myproject.dev. Let's start with creating the certificate.
Again, I've found this little tool called create-ssl-certificate that will generate for you an SSL certificate for a specific local domain. This too is very easy to use, the only not so clear part is that it is a NPM package that you can install globally with npm -g install create-ssl-certificate.
If everything went well with create-ssl-certificate, you should now have two files, just like it was with localhost in step 1. By default, create-ssl-certificate calls the generated files ssl.crt and ssl.key. I've renamed them as server.crt and server.key to be consistent with the localhost files. Then I've created a ssl folder in the myproject root folder, and moved the files in there.
Let's forget about the files for a moment and proceed to some Apache configuration.
4) Configure MAMP's Apache to accept Virtual Hosts
If you've created virtual hosts before, you have probably already done this, so you can skip this step.
The only thing we need to do to 'activate' the possibility of creating virtual hosts is to go to /Applications/MAMP/conf/apache/httpd.conf and uncomment this line:
Include /Applications/MAMP/conf/apache/extra/httpd-vhosts.conf
5) Configure your local domain's Virtual Host for SSL
Now we can set up a virtual host so that we can access myproject at https://myproject.dev. First of all, edit your hosts file and add this line:
127.0.0.1 myproject.dev
Then, go to /Applications/MAMP/conf/apache/extra/httpd-vhosts.conf and add the following:
<VirtualHost myproject.dev:443>
ServerName myproject.dev
DocumentRoot "/Users/myusername/Sites/myproject"
SSLEngine on
SSLCertificateFile "/Users/myusername/Sites/myproject/ssl/server.crt"
SSLCertificateKeyFile "/Users/myusername/Sites/myproject/ssl/server.key"
</VirtualHost>
With this configuration, you will be able to access https://myproject.dev because the server is instructed to search for the SSL certificates we've created in step 4.

SSL certificate for specific directories

So I've got a login script (domain.com/script/index.php) that I need protected with a self-signed certificate, but installing a cert with Apache will apply it to my whole domain. My domain is a personal website, and the last thing I would want is for someone to go through the hassle of having to jump through the hoops of having to 'trust' my self-signed certificate.
Right now I have Webmin running on my server, and it currently has its own self-signed without applying it to my root website directory. Is there any way to secure my script directory without applying it to my root directory?
I'm gonna assume this is php and apache:
Just add this lines to your vhost configs:
SSLEngine on
SSLCertificateFile {{SERVER CRT PATH}}
SSLCertificateKeyFile {{SERVER CRT PATH}}
Make sure SSL dll is on in the php.ini
and apply like so:
# Local Php site
<VirtualHost *:83>
ServerName localhost
DocumentRoot C:/xampp2/htdocs/scripts/php
<Directory C:/xampp2/htdocs/scripts/php>
AllowOverride All
Require all granted
</Directory>
SSLEngine on
SSLCertificateFile C:\xampp2\apache\conf\ssl.crt\server.crt
SSLCertificateKeyFile C:\xampp2\apache\conf\ssl.key\server.key
</VirtualHost>
Reference: http://robsnotebook.com/xampp-ssl-encrypt-passwords
restart apache then visit: https://localhost:83

Making an exception for SSLVerifyClient require

I have apache2 httpd version 2.2.9 listening on port 443 with SSLEngine on. All URLs have SSLVerifyClient require and this works fine.
I want to make an exception for a specific URL (/ca.crt) so that my clients can download the certificate of the CA that the certificates we issue them are signed with. I try the following:
SSLVerifyClient require
Alias /ca.crt /my/ssl/certs/ca.crt
<Location /ca.crt>
SSLVerifyClient none
</Location>
My problem is that Apache only seems to want to increase the strength of the SSL client certificate requirement. If I flip the two requirements around, it works as specified. As it is configured above, Apache effectively ignores the SSLVerifyClient none directive.
What's going on? Is this a bug?
Ok, it turns out that the answer to this question is in the documentation (as it usually is!)
In per-server context [the SSLVerifyClient directive] applies to
the client authentication process used
in the standard SSL handshake when a
connection is established.
See Apache Docs - SSLVerifyClient
Basically the first SSLVerifyClient directive was in the per-server context. I made an explicit <Directory> declaration for the root directory and put the SSLClientVerify require directive in there. This did the trick.

Apache Name Virtual Host with SSL

I am attempting to setup our servers to allow traffic over SSL. I am aware that SSL does not work with Name Virtual Host, but we have all of our Apache servers on virtual machines with dedicated private IPs. We have a primary virtual machine that has mod_proxy setup to route traffic to the appropriate VMs.
However, in order to route HTTPS traffic we need to have the certificate installed on the proxy as well as the VMs. We have a wildcard certificate that can be used across all of our hosts. Everything appears to work properly, but I receive the following in the Apache logs for the proxy:
[warn] Init: SSL server IP/port conflict: host1.example.com:443 (/etc/apache2/sites-enabled/host1:1) vs. host2.example.com:443 (/etc/apache2/sites-enabled/host2:1)
There is one of these error message for each host we have setup on the proxy. Our Virtual Host setup for the proxy is posted below:
<VirtualHost ipaddress:443>
ServerName host1.example.com
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / https://privateip:443/
ProxyPassReverse / https://privateip:443/
SSLProxyEngine on
SSLEngine on
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
</VirtualHost>
Is there any way that I can get this to work?
It sounds like Apache is warning you that you have multiple <VirtualHost> sections with the same IP address and port... as far as getting it to work without warnings, I think you would need to use something like Server Name Indication (SNI), a way of identifying the hostname requested as part of the SSL handshake. Basically it lets you do name-based virtual hosting over SSL, but I'm not sure how well it's supported by browsers. Other than something like SNI, you're basically limited to one SSL-enabled domain name for each IP address you expose to the public internet.
Of course, if you are able to access the websites properly, you'll probably be fine ignoring the warnings. These particular ones aren't very serious - they're mainly an indication of what to look at if you are experiencing problems
As far as I know, Apache supports SNI since Version 2.2.12
Sadly the documentation does not yet reflect that change.
Go for http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI until that is finished
You may be able to replace the:
VirtualHost ipaddress:443
with
VirtualHost *:443
You probably need todo this on all of your virt hosts.
It will probably clear up that message. Let the ServerName directive worry about routing the message request.
Again, you may not be able to do this if you have multiple ip's aliases to the same machine.
The VirtualHost would look like this:
NameVirtualHost IP_Address:443
<VirtualHost IP_Address:443>
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/ca.crt # Where "ca" is the name of the Certificate
SSLCertificateKeyFile /etc/pki/tls/private/ca.key
ServerAdmin webmaster#example.com
DocumentRoot /var/www/html
ServerName www.example.com
ErrorLog logs/www.example.com-error_log
CustomLog logs/www.example.com-access_log common
</VirtualHost>
First you need NameVirtualHost ip:443 in you config file!
You probably have one with 80 at the end, but you will also need one with 443.
Second you need a *.domain certificate (wildcard) (it is possible to make one)
Third you can make only something.domain webs in one ip (because of the certificate)
You MUST add below part to enable NameVirtualHost functionality with given IP.
NameVirtualHost IP_Address:443
Apache doesn't support SSL on name-based virtual host, only on IP based Virtual Hosts.
Source: Apache 2.2 SSL FAQ question Why is it not possible to use Name-Based Virtual Hosting to identify different SSL virtual hosts?
Unlike SSL, the TLS specification allows for name-based hosts (SNI as mentioned by someone else), but Apache doesn't yet support this feature. It supposedly will in a future release when compiled against openssl 0.9.8.
Also, mod_gnutls claims to support SNI, but I've never actually tried it.