One Site Multiple Certificate

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?

Who is Participating?
John Mc HaleConnect With a Mentor Forensic Computer Examiner, Analyst/Programmer & Database ArchitectCommented:

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

You mean server certificates?  There is a way (TLS extension - Server Name Indication) -- check out
archerlogicAuthor Commented:
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?
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

Yeah, still more confusing.  Do you need to identify these remote servers?  Then maybe you are talking about different *client* certificates?
archerlogicAuthor Commented:
yes, different client certificates but all connecting to the same site. Possible?
John Mc HaleForensic Computer Examiner, Analyst/Programmer & Database ArchitectCommented:
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

archerlogicAuthor Commented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.