I've been trying to setup client certificate authentication for almost three days now but to no avail.
I've signed up for a free domain at heliohost and have installed a free ssl certificate issued by Let's encrypt.
My plan is to have self signed certificates and check them against the database later(for user authentication) therefore I set my SSLVerifyClient to optional_no_ca in the htaccess file. I installed several self signed certificates generated by openssl but no matter which browser I try(Chrome, Firefox or IE) I get no prompts to choose a certificate except when i tried to access it on my phone via Chrome, in this case it offers to install a certificate since I don't have any on the phone.
This is the content of my .htaccess file:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
SSLOptions +StdEnvVars
SSLRequireSSL
SSLVerifyDepth 1
SSLVerifyClient optional_no_ca
I would really appreciate any feedback pertaining the issue, this is my first time trying to implement this and I'm not sure weather the issue is with my setup or chrome.
also I'm using chrome 59
Kriss
You have omitted the part of the ssl certificate authorities configuration. it is needed to configure the CA certificate that signs your client certificates ( see this
SSLCACertificateFile "conf/ssl.crt/ca.crt"
The server is not sending the root CA, then since you have set SSLVerifyClient to optional_no_ca, the browser automatically performs the connection because it can not find any suitable certificate (see below TLS1.2 note)
Since you have set optional_no_ca in your server, it accepts the connection even if no certificate is presented. It you set require you will find that the connection fails with Chrome.
SSLCACertificateFile is not configurable in .htaccess. Since you can not customize chrome, i am afraid you need to configure this parameter to force certificate prompt
When the certificate list is empty, the behavior between browsers may vary because the TLS specification allows it
See TLS1.2 RFC
7.4.4. Certificate Request
certificate_authorities
A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded format. These
distinguished names may specify a desired distinguished name for a
root CA or for a subordinate CA; thus, this message can be used to
describe known roots as well as a desired authorization space. If
the certificate_authorities list is empty, then the client MAY
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary.
7.4.6. Client Certificate
[...]
If the client does not send any certificates, the
server MAY at its discretion either continue the handshake without
client authentication, or respond with a fatal handshake_failure
alert.
The issue was due to chrome, I have unfortunately not been able to pinpoint it but managed to get it working and prompting me for the certificate on firefox.
Thank you for the answers.
Related
I've been trying to communicate with my hosting provider for over a month now, but I'm 99% sure they don't even read the tickets and respond with randomly generated string of words.
I searched for weeks for the answer to this, and I see some mentions in regards to updating Java or modifying files that I don't have access to. Now, this is what happens for me. If I try to validate my domain name with W3C or try to validate a Twitter Card, I keep getting the SSL Handshake Error:
ERROR: Fetching the page failed because SSL handshake error.
I have a wildcard SSL from Comodo.
If I remove these lines from .htaccess W3C validates, but Twitter Card doesn't:
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^www.iadb.com$ [OR]
RewriteCond %{HTTP_HOST} ^iadb.com$
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Unfortunately if I change this, https is not enforced in any way, not to mention that it doesn't fix the Twitter issue. Again, since it's a shared host, I don't have access to any configuration other than .htaccess - I would appreciate any help or hints, even if it's just to tell me that I'm SOL.
Some tests with openssl s_client and packet captures reveal that your server returns a TLS alert unregognized_name with level warning if you access the host as iadb.com but that the TLS alert does not happen when using www.iadb.com as hostname. But since you redirect from https://www.iadb.com to http://iadb.com you end up with a connection containing this TLS alert.
Although the TLS alert level is warning only some implementations (openssl 0.9.8, Java) interpret it as error which causes the handshake to fail. This is what you see for example with the W3C validator:
IO Error: handshake alert: unrecognized_name
While this client software obviously behaves wrong it is also bad that the server sends this TLS alert at all. My guess is that this is caused because the server is only configured for the hostname www.iadb.com but not for iadb.com but you explicitly use the latter name. One way to work around the problem by yourself is to use only www.iadb.com. Another way is to fix the server configuration which according to your description only can be done by the hosting provider.
I would first like to first say, this is not good practice and we should endevour to have everything on HTTPS 100% of the time but in this case I had a series of awkward requirements on a system that did not hold sensitive information. I was quite ignorant of how HTTPS/TLS worked when asking this question back when I was more junior but have left it in place to help others as it receives a fair amount of attention. I recommend reading Oreily's TLS 101 if you're interested.
You can now get free TLS certificates using Let's Encrypt which I thoroughly recommend. Lastly, if you are using the default Apache config please check out Mozilla's SSL config generator selecting 'Modern' after entering your apache version.
I am hosting a couple of seperate websites on one apache server:
site.com
site.com redirects all users to HTTPS from within the application.
example.com
example.com is an HTTP website and HTTPS requests are redirects to HTTP
In order for accidental requests for https://example.com instead of http://example.com to not get site.com (due to when only one HTTPS vhost is used that becomes the default site) I need to set up an https vhost for example.com but I have to use a self signed cert as there is no reason for the site to use an SSL.
This means when someone visits https://example.com they get a browser warning page that the SSL is self signed and then as soon as they click continue they get redirected to HTTP
Is there any way to redirect HTTPS requests to HTTP without a certificate
This is the current vhost:
<VirtualHost *:443>
ServerName about.example.com:443
DocumentRoot "/directory"
<Directory "/directoy">
AllowOverride All
Require all granted
</Directory>
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
SSLEngine on
SSLCertificateFile /etc/httpd/ssl/ExampleCOM.pem
SSLCertificateKeyFile /etc/httpd/ssl/AboutExampleCOM-key.pem
Header always set Strict-Transport-Security "max-age=15768000"
</VirtualHost>
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
# Disabled to avoid CRIME attack
SSLCompression off
# this usually compromises perfect forward secrecy
SSLSessionTickets off
# OCSP Stapling, httpd 2.3.3 or later
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)
Fundamentally, that's a problem. When communicating over HTTPS, the TLS communication layer is set up before anything is exchanged, i.e. the warning about the certificate happens before any information about the website is transferred. So a Certificate is needed to allow a browser to connect when https is defined, self signed or not.
Ideally, and for 'best practice' we should really be encouraging people to use HTTPS as default (I realise this is an expense and can be annoying with certificates, and whilst there shouldn't be anything wrong with self signed certificates, there often are problems and browser messages etc).
Even if you have an application server which 'can only do http', best practice is generally to front that application server with a Web Server (such as nginx or lighthttpd or some form of load balancer) which also will provide your https termination. - which is what you seem to have done with your httprewrite which forwards the request to your site.
You might find some cheap SSL-certificate providers which are installed in most browsers though?
Short answer. No there is not a way to do this.
The connection to https happens before any type of redirection happens. The only thing you can do is buy a cert. Regular domain certs are super cheap these days.
You can get a valid domain cert for $4.99/yr. Then do the redirection so that both https and http are covered.
Or you can turn off your 443 vhost but the user will get a 404 or connection error page. If they try https.
Those are your options. Your users will always get that warning page as long as it's self signed and that's by design.
I have a NodeJS server on Amazon EC2.
I'm trying to set up SSL using certificates from "COMODO RSA Domain Validation Secure Server CA".
I got it working for all browsers except Firefox. Is this a common issure?
Please check that the server provides all intermediate certificates (trust chain). A common issue is to forget the intermediate certificates and then get errors on some browsers an no errors on others. This is caused by the browsers caching the intermediate certificates, e.g. if you've visited a site using the same intermediate certificates before, the browser will dutifully use these cached intermediates if the server forgot to server them. But, if the browser never visited such site before the intermediates are not cached and thus the verification will fail.
A good test is to use openssl s_client -connect your.https.server:443 and look at the chain of certificates it provides. Also, https://www.ssllabs.com/ssltest/analyze.html will point out such problems.
OK I have a SSL issue that I can't seem to get past on this 1 Win7 x64 machine. I have been using self-signed certs for years and even blogged about them before so I have experience. However something is happening that I can't figure out this time.
I have (2) localhost SSL certs created and insalled on my machine.
localhost (friendly name) issued and created in IIS (7.5). It contains the 'Issued To' and 'Issued By' values of my machine name: 'DevMachine123'. This is the certificate being served up for applications configured under the 'Default Web Site' in IIS.
localhost SSL certificate created using makecert.exe tool where CN=localhost (common name) was used. It contains the 'Issued To' and 'Issued By' values of 'localhost'. This is the SSL cert I want served up in IIS for my applications configured under the 'Default Web Site'.
The error I'm getting is:
'The security certificate presented by this website was issued for a
different website's address.'
When I view the certificate being served up from the IE browser: it shows the localhost cert issued to 'DevMachine123' is being used and not the localhost issued to localhost (#2 above) which should resolve this issue. Hence the name mismatch because 'DevMachine123' does not match 'localhost'.
Another point to make; my certificates have been added to 'Trusted Root Certification Authorities' so they both are trusted certificates.
Last point to make, I checked the https port 443 Binding configuration for the 'Default Web Site' on my machine in IIS. I view the certificate and it shows the correct localhost certificate is bound (#2 above with CN=localhost).
I feel that I have covered my bases here (yes I have seen this and this so please do not re-post). What am I missing here?
Thanks!
I had a similar issue and had also gone through the checks you mentioned above for the site bindings. I ran the following netsh command
netsh http show sslcert
This showed me two SSL Certificate bindings. One on IP:Port 0.0.0.0:443 with the correct certificate and one on IP:Port [::]:443 with an expired certificate. I opened CertMgr.msc for the Local Computer (see here for instructions) and searched for the invalid certificate and discovered it had expired.
To resolve the issue I did the following
netsh http delete sslcert ipport=[::]:443
iisreset /restart
Very similar answer to #IsolatedStorage but with some more details of what helped me.
First a couple points that are probably the same for you
I was trying to update a certificate because it has expired.
I have multiple domains bound to the same IP. They happen to be a SAN certificate but that's probably irrelevant.
I was trying to use the centralized certificate store. Again I think this is irrelevant to most of my answer.
I had already attempted to update the certificate but it wasn't showing the new date.
You're probably in a panic right now if your old certificate already expired. Take a deep breath...
First I'd recommend strongly going to https://www.digicert.com/help/ and downloading their DigiCert tool. You can also use it online.
Enter in your website https://example.com and it will show you the expiration date and thumbprint (what MS calls the certificate hash). It does a realtime lookup so you don't have to worry whether or not your browser (or intermediate server) is caching something.
If you're using the centralized certificate store you'll want to be 100% sure the .pfx file is the latest version so go to your store directory and run this command:
C:\WEBSITES\SSL> certutil -dump www.example.com.pfx
This will show you the expiration date and hash/thumbprint. Obviously if this expiration date is wrong you probaly just exported the wrong certifcate to the filesystem so go and fix that first.
If you are using the CCS then assuming this certutil command gives you the expected expiration date (of your updated certificate) you can proceed.
Run the command:
netsh http show sslcert > c:\temp\certlog.txt
notepad c:\temp\certlog.txt
You likely have a lot of stuff in here so it's easier to open it up in a text editor.
You'll want to search this file for the WRONG hash that you got from digicert.com (or the thumbprint you got fromChrome).
For me this yielded the following. You'll see it is bound to an IP and not my expected domain name. This is the problem. It seems that this (for whatever reason I'm not sure) takes precedence over the binding set in IIS that I just updated for example.com.
IP:port : 10.0.0.1:443
Certificate Hash : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
I don't even know where this binding came from - I don't even have any SSL bindings on my default site but this server is a few years old and I think something just got corrupted and stuck.
So you'll want to delete it.
To be on the safe side you'll want to run the following comand first to be sure you're only deleting this one item:
C:\Windows\system32>netsh http show sslcert ipport=10.0.0.1:443
SSL Certificate bindings:
-------------------------
IP:port : 10.0.0.1:443
Certificate Hash : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Now we've verified this is the 'bad' thumbprint, and expected single record we can delete it with this command:
C:\Windows\system32>netsh http delete sslcert ipport=10.0.0.1:443
SSL Certificate successfully deleted
Hopefully if you now go back to Digicert and re-run the command it will give you the expected certificate thumbprint. You should check all SAN names if you have any just to be sure.
Probably want to IISRESET here to be sure no surprises later.
Final note: If you're using the centralized certificate store and you're seeing erratic behavior trying to even determine if it is picking up your certificate from there or not don't worry - it's not your fault. It seems to sometimes pick up new files immediately, but cache old ones. Opening and resaving the SSL binding after making any kind of change seems to reset it but not 100% of the time.
Good luck :-)
Same symptoms
Changed HTTPS binding in the drop down list to the server IP (in the site bindings dialog). It was set to "all unassigned" Got a warning about overwriting an existing certificate / IP combination, which I accepted, and and issue resolved.
Verify you have only one site set per binding in IIS as well.
If the Default site and a separate one are installed, they may both have an HTTPS binding on the same port. If this happens, the cert served may be the one from the other site.
I'm using gmail from work, but I need to enter a password for a proxy when accesing the first web page. The password is asked from inside the browser. I receive a certificate from the proxy which I must accept in order to make the Internet connection work.
Can my HTTPS connection, between gmail and browser, be tracked in this situation?
Fiddler describes it like this:
Q: The HTTPS protocol was designed to prevent traffic viewing and tampering. Given that, how can Fiddler2 debug HTTPS traffic?
A: Fiddler2 relies on a "man-in-the-middle" approach to HTTPS interception. To your web browser, Fiddler2 claims to be the secure web server, and to the web server, Fiddler2 mimics the web browser. In order to pretend to be the web server, Fiddler2 dynamically generates a HTTPS certificate.
Fiddler's certificate is not trusted by your web browser (since Fiddler is not a Trusted Root Certification authority), and hence while Fiddler2 is intercepting your traffic, you'll see a HTTPS error message in your browser, like so:
tracked? Well even though https encrypts the traffic you still know the ip address of both parties (gmail and the browser). HTTPS doesn't solve this problem, but a different blend of crypto has created The Onion Router(TOR) which does make impossible to locate both servers and clients.
Under "normal" conditions when an attacker is trying to MITM HTTPS your browser should throw a certificate error. This is the whole point of SSL backed by a PKI. HOWEVER in 2009 Moxie Marlenspike gave a killer Blackhat talk in which he was able to MITM HTTPS without warning. His tools is called SSLStrip, and I highly recommend watching that video.
A good solution to SSLStrip was developed by Google. Its called STS, and you should enable this on all of your web applications. Currently sts is only supported by Chrome, but Firefox is working on their supporting this feature. Eventually all browsers should support it.
Yes they can. You can see this for yourself by downloading Fiddler and using it to decrypt https traffic. Fiddler issues its own certificate and acts a man in the middle. You would need to view the certificate in your browser to see whether it is actually issued by gmail.
It seems that the renegotiation is a weak spot in the TSLv1 (see TLS renegotiation attack. More bad news for SSL).
As pointed out by other answers (read also here) for this to work really "in the middle" (i.e. excluding the cases in which the capturing occurs at one of the end-points, inside the browser or inside the web server), some kind of proxy must be set, who speaks to your browser and to the server, pretending to both to be the other side. But your browser (and ssl) is smart enough to realize that the certificate that the proxy sends you ("saying: I am gmail") is illegal, i.e. is not signed by a trusted Root Certification authority. Then, this will only work if the user explicitly accepts that untrusted certificate, or if the CA used by the proxy was inserted into the trusted CA registry in his browser.
In summary, if the user is using a clean/trusted browser installation, and if he refuses certificates issued by untrusted authorities, an man "in the middle" cannot decrypt an https communication.
It cannot be tracked between the gmail webserver and your pc, but once it is inside the pc, it can be tracked. I dont understand how two people claim that https can be tracked with mitm since the whole purpose of https is to prevent such attacks.
The point is that all HTTP level messages are encrypted, and mac-ed. Due to the certificate trust chain, you cannot fake a certificate, so it should not be possible to perform a man in the middle.
The ones who claim it is possible, can you please give details about how and why it is possible and how the existing countermeasures are circumvented?