I purchased a Comodo SSL certificate (OV), and set up the Apache vhost config so that all traffic is forwarded to 443. Intermittently some users are being prompted to supply a client certificate; these users all seem to be OSX users, but it happens on both Safari and Chrome. Why does this happen? Why is it only OSX, and how can I stop this from happening?

I added the SSLVerifyClient line as shown as an experiment after this started happening (the default is none, but I wanted to try being explicit).

My vhost configuration follows at the end of the post.

Here are some of the screenshots from users (which, incidentally, is really a bad UX -- it surprises me that this shows up at all in OSX):




Here's my vhost config:

<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/

<VirtualHost *:443>
    Header add Strict-Transport-Security "max-age=15768000"

    ServerAdmin example@yyy.com
    ServerName www.example.com
    ServerAlias example.com
    SetEnv APPLICATION_ENV production

    SSLEngine on
    SSLCertificateFile    /etc/apache2/ssl/example_com.crt
    SSLCertificateKeyFile /etc/apache2/ssl/example.key
    SSLCertificateChainFile /etc/apache2/ssl/example_com.ca-bundle
    SSLVerifyClient none

    BrowserMatch "MSIE [2-6]" \
            nokeepalive ssl-unclean-shutdown \
            downgrade-1.0 force-response-1.0
    # MSIE 7 and newer should be able to use keepalive
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

    AddHandler php5-fcgi .php
    Action php5-fcgi /php5-fcgi
    Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi -socket /var/run/php5-fpm.sock -pass-header Authorization

    <FilesMatch "\.(cgi|shtml|phtml|php)$">
            SSLOptions +StdEnvVars
    <Directory /usr/lib/cgi-bin>
            SSLOptions +StdEnvVars

    DocumentRoot /usr/local/zend/example/public
    <Directory /usr/local/zend/example/public>
            Options Indexes FollowSymLinks
            AllowOverride All
            allow from all
            php_admin_value open_basedir none

There is an .htaccess in the public dir:

RewriteEngine On
RewriteRule ^(.*)\.[\d]{10}\.(css|js)$ $1.$2 [L]

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
  • Almost all client certificate UI's are horrible. Perhaps you're behind a load balancer or your firewall has a broken reverse NAT, where it's shuffling traffic between many hosts. – halfbit Jan 17 '14 at 20:56
  • @makerofthings7 This is a website on digital ocean -- I'm not running a load balancer myself. However I just ran a traceroute, and there are indeed several hops once it gets to their network, so sounds like the problem might be a config issue on one of their servers? – confused Jan 17 '14 at 20:59
  • yes, open a ticket with them. – halfbit Jan 17 '14 at 21:40
  • @makerofthings7 no good. They said "seems unlikely, as we'd have heard the same from other users". This has been happening over 14 days so while their response is a little glib it also seems fair enough. – confused Jan 17 '14 at 22:12
  • Generally you only get the client certificate UI if the client actually has a certificate installed. That explains why only certain users are affected. Try Fiddler to make sure some other resource .htaccess isn't configured with SSLVerifyClient optional or something. find/grep may help. – Ben Jan 20 '14 at 17:05

An SSL client will use a client certificate only if duly requested by the server. If both Chrome and Safari claim that the server requests a client certificate, then this probably means that the server indeed requests a client certificate. As was pointed out by @Ben, it is quite possible that the server requests certificates for everybody, but most non-OSX users don't have certificates at all and their browser silently answers to the server that they don't have any certificate.

To be sure that a certificate is indeed requested by the server, run Wireshark. You should be able to see the SSL handshake details, in particular the CertificateRequest handshake message from the server. You will also want to check that the server who requests a client certificate is indeed yours: verify that the Certificate message from the server contains the exact certificate that you configured on your server.

In any case, since the SSL handshake contains checksums which are computed over all exchanged handshake messages, a CertificateRequest message cannot be smuggled into your handshakes without breaking the procedure (client and/or server will complain loudly).

Unfortunately, the two suggested scenarios don't ultimately work:

  • If there is some load balancer misconfiguration which redirects some clients to another server, that other server should not have a certificate matching your site name. Client browsers should flash their scary warning popups. On the other hand, if the other server actually has a certificate with your site name in it, then this is an attack, and a very successful one; it would make little sense for the attacker to blow his own cover by stupidly asking for client certificates.

  • If the problem is a misconfiguration on your own server (e.g. a .htaccess file which overrides your SSLVerifyClient setting), then the problem should not be intermittent. For a given URL, it should always happen, or never.

My best guess (not a good guess, but the best I can offer) is that your site embeds some advertisements from a third-party ad provider, and some of these ads point to a misconfigured SSL-powered server. This would explain the "intermittent" part: you get the certificate popup on the random occasion where the ad provider points you at that specific misconfigured server. Trace analysis with Wireshark would reveal that, by the way: if you find a SSL handshake with a CertificateRequest message, then the corresponding Certificate message will contain the offending server's certificate, and the server's name (and you should also find it as part of the Server Name Indication extension in the ClientHello message). So go install Wireshark and see for yourself.

(On Windows, Microsoft's Network Monitor would work equally well.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.