One Site Multiple Certificate

Posted on 2007-11-21
Last Modified: 2008-08-26
I have a web applicaiton which acts as a web service that allow multiple parties to connect to, to retrieve information.
The website will be SSL protected with mod_ssl.
Is there anyway to allow different clients to connect to one same site but with different certificates?

Question by:archerlogic
  • 3
  • 2
  • 2

Expert Comment

ID: 20329468
You mean server certificates?  There is a way (TLS extension - Server Name Indication) -- check out

Author Comment

ID: 20332329
Sorry for not being clear.

For example I have a script atl I will be having other multiple remote servers that will do a HTTPS POST to this script. Is it possible that these multiple remote servers use a different SSL certificate to connect to my site or do they have to use the same one?

Hope I am clear now, or am I more confusing?

Expert Comment

ID: 20332800
Yeah, still more confusing.  Do you need to identify these remote servers?  Then maybe you are talking about different *client* certificates?
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Author Comment

ID: 20332855
yes, different client certificates but all connecting to the same site. Possible?
LVL 13

Expert Comment

by:John Mc Hale
ID: 20342248
You should be able to do this with configuration directives:

SSLVerifyClient require
# optionally specify hierarchical verification  depth
# check client certificate's common name
SSLRequire (     %{SSL_CLIENT_S_DN_CN} eq "server1commonname" \
                      or %{SSL_CLIENT_S_DN_CN} eq "server2commonname" \
                      or %{SSL_CLIENT_S_DN_CN} eq "server1commonname"


SSLRequire (     %{SSL_CLIENT_S_DN_CN} eq "server1commonname" \
                      || %{SSL_CLIENT_S_DN_CN} eq "server2commonname" \
                      || %{SSL_CLIENT_S_DN_CN} eq "server3commonname"
) # etc. etc.

You can also test client connections using their ip addresses:

SSLRequire( %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$ )

... but i've never used the 2nd one


Author Comment

ID: 20347904
Question, is this used for when multiple clients with different certs connect to one site?

Where do I put in the path of the cert? Would be great if you explain what these chunk does. thanks
LVL 13

Accepted Solution

John Mc Hale earned 500 total points
ID: 20356842

the directive SSLVerifyClient require

just verifies that connecting clients are using SSL; i.e. that insercure connections are not accepted.

the directive SSLRequire can be used with any valid variables (much like environment variables), so...

what the SSLRequire block:

SSLRequire (     %{SSL_CLIENT_S_DN_CN} eq "server1commonname" \
                      || %{SSL_CLIENT_S_DN_CN} eq "server2commonname" \
                      || %{SSL_CLIENT_S_DN_CN} eq "server3commonname"

would do is to examine the common name of the certificate issued to whatever clients you wish to accept connections from, and if the value of the common name is 'server1commonname' or 'server2commonname' or 'server3commonname' then the connection is accepted. Naturally, you would change the 'serverxcommonname' to whatever the common names of each connecting client are.

Unless the connecting clients have fixed IP addresses, then relying on the %{REMOTE_ADDR} variable is unwise, as dynamically allocated ip addresses, by their nature, change.

Generally speaking, it is a bad idea to have server-wide SSL, unless your site is limited to a small amount of served pages, as performance will be affected.

So, you would normally enable SSL within a virtual host; (see code snippet).

Then you protect the directories/locations that you require SSL for, using Diectory or Location constructs in your httpd configuration file, or alternatively, on a per-directory basis in a .htaccess file;


<Directory "C:/Apache/htdocs/private" >
SSLVerifyClient require
SSLRequire (     %{SSL_CLIENT_S_DN_CN} eq "server1commonname" \
                      || %{SSL_CLIENT_S_DN_CN} eq "server2commonname" \
                      || %{SSL_CLIENT_S_DN_CN} eq "server3commonname"


SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
Listen 443
#   Some MIME-types for downloading Certificates and CRLs
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl
SSLPassPhraseDialog  builtin
#   Inter-Process Session Cache:
#   Configure the SSL Session Cache: First the mechanism 
#   to use and second the expiring timeout (in seconds).
#SSLSessionCache         dbm:c:/Apache/logs/ssl_scache
SSLSessionCache        shmcb:c:/Apache/logs/ssl_scache(512000)
SSLSessionCacheTimeout  300
#   Semaphore:
#   Configure the path to the mutual exclusion semaphore the
#   SSL engine uses internally for inter-process synchronization. 
SSLMutex default
## SSL Virtual Host Context
#NameVirtualHost inspiron-xpm-01:443
<VirtualHost _default_:443>
#   General setup for the virtual host
#DocumentRoot "C:/apache/htdocs"
ErrorLog C:/Apache/logs/error_ssl.log
TransferLog C:/Apache/logs/access_ssl.log
#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on
#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
#   Server Certificate:
#   Point SSLCertificateFile at a PEM encoded certificate.  If
#   the certificate is encrypted, then you will be prompted for a
#   pass phrase.  Note that a kill -HUP will prompt again.  Keep
#   in mind that if you have both an RSA and a DSA certificate you
#   can configure both in parallel (to also allow the use of DSA
#   ciphers, etc.)
SSLCertificateFile C:/myCA/certs/server.crt
#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile C:/myCA/private/server.key
#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate. Alternatively
#   the referenced file can be the same as SSLCertificateFile
#   when the CA certificates are directly appended to the server
#   certificate for convinience.
#SSLCertificateChainFile c:/Apache/conf/server-ca.crt
#   Certificate Authority (CA):
#   Set the CA certificate verification path where to find CA
#   certificates for client authentication or alternatively one
#   huge file containing all of them (file must be PEM encoded)
#   Note: Inside SSLCACertificatePath you need hash symlinks
#         to point to the certificate files. Use the provided
#         Makefile to update the hash symlinks after changes.
SSLCACertificateFile C:/myCA/certs/myca.crt
#   Certificate Revocation Lists (CRL):
#   Set the CA revocation path where to find CA CRLs for client
#   authentication or alternatively one huge file containing all
#   of them (file must be PEM encoded)
#   Note: Inside SSLCARevocationPath you need hash symlinks
#         to point to the certificate files. Use the provided
#         Makefile to update the hash symlinks after changes.
#SSLCARevocationFile c:/Apache/conf/ssl.crl/ca-bundle.crl
#   SSL Protocol Adjustments:
#   The safe and default but still SSL/TLS standard compliant shutdown
#   approach is that mod_ssl sends the close notify alert but doesn't wait for
#   the close notify alert from client. When you need a different shutdown
#   approach you can use one of the following variables:
#   o ssl-unclean-shutdown:
#     This forces an unclean shutdown when the connection is closed, i.e. no
#     SSL close notify alert is send or allowed to received.  This violates
#     the SSL/TLS standard but is needed for some brain-dead browsers. Use
#     this when you receive I/O errors because of the standard approach where
#     mod_ssl sends the close notify alert.
#   o ssl-accurate-shutdown:
#     This forces an accurate shutdown when the connection is closed, i.e. a
#     SSL close notify alert is send and mod_ssl waits for the close notify
#     alert of the client. This is 100% SSL/TLS standard compliant, but in
#     practice often causes hanging connections with brain-dead browsers. Use
#     this only for browsers where you know that their SSL implementation
#     works correctly. 
#   Notice: Most problems of broken clients are also related to the HTTP
#   keep-alive facility, so you usually additionally want to disable
#   keep-alive for those clients, too. Use variable "nokeepalive" for this.
#   Similarly, one has to force some clients to use HTTP/1.0 to workaround
#   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
#   "force-response-1.0" for this.
BrowserMatch ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
#   Per-Server Logging:
#   The home of a custom SSL log file. Use this when you want a
#   compact non-error SSL logfile on a virtual host basis.
CustomLog "C:/Apache/logs/ssl_request.log" \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Open in new window


Featured Post

Announcing the Most Valuable Experts of 2016

MVEs are more concerned with the satisfaction of those they help than with the considerable points they can earn. They are the types of people you feel privileged to call colleagues. Join us in honoring this amazing group of Experts.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

As Wikipedia explains 'robots.txt' as -- the robot exclusion standard, also known as the Robots Exclusion Protocol or robots.txt protocol, is a convention to prevent cooperating web spiders and other web robots from accessing all or part of a websit…
I have seen several blogs and forum entries elsewhere state that because NTFS volumes do not support linux ownership or permissions, they cannot be used for anonymous ftp upload through the vsftpd program.   IT can be done and here's how to get i…
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…

749 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question