httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Httpd Wiki] Update of "ScratchPad" by jmcg
Date Fri, 09 Sep 2011 10:24:29 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.

The "ScratchPad" page has been changed by jmcg:
http://wiki.apache.org/httpd/ScratchPad?action=diff&rev1=43&rev2=44

- Understanding Multi-Use Digital Certificates
+ = Understanding Multi-Use Digital Certificates =
  
- Abstract
+ == Abstract ==
  With the proliferation of internal Web-based services that must be exposed to the Internet,
organizations are turning more and more to the use of SSL certificates. However, using traditional
SSL certificates can become cumbersome and quite expensive, especially when organizations
offer several Internet-facing services. This is where multi-use certificates -- certificates
that can be reused for different purposes -- can help. Using a single multi-use certificate,
organizations can reduce costs and simplify certificate management.
  
- "'Introduction'"
+ == Introduction ==
  The best way to prove who you are on the Internet is to use a digital certificate. That's
because a digital certificate relies on a trusted, third-party authority to verify your identity.
In fact, it uses a chain of trust that begins with you and works its way up to the trusted
authority that validates who you are. This chain of trust provides verifiable Internet security.
  
  Take Internet user Bill for example. Bill uses a digital certificate to sign all of his
emails. This example demonstrates the concept of authenticity. The certificate authenticates
Bill as the author of the email.
@@ -17, +17 @@

  
  Similarly, organizations that process transactions on the Internet or that offer Internet-based
services need to rely on digital certificates to validate that they are who they claim to
be; otherwise, no one will trust their services. Most organizations do this by adding certificates
to their Internet-facing servers. When users access a web page hosted on one of these servers,
their Web browser will automatically detect the certificate and modify the session, from an
open session using the HyperText Transfer Protocol (HTTP) to secure HTTP (HTTPS).   This will
allow for the encryption of all the data sent between the user's workstation and the server.
HTTPS data encryption is provided by the Secure Sockets Layer (SSL). Basically, SSL creates
an encryption tunnel between the client and the server protecting the transfer of data from
one point to the other during the communication exchange. You know you are using SSL when
your browser displays a closed padlock in its status bar. 
  
- "'Working with SSL Certificates'"
+ == Working with SSL Certificates ==
  In order to enable SSL on their external-facing servers, organizations must purchase a certificate
from a trusted certification authority for each protected service they provide. Today, organizations
can offer several services to their end users -- email, instant messaging, mobile device management,
Web-based interactions and more -- and each one of the servers providing these services requires
its own certificate. 
  
  SSL certificates are tied to the unique domain name on which a service is hosted. Embedding
the domain name into the certificate is important since this makes it possible to ensure the
identity of the remote computer providing the service by comparing the domain name being accessed
to the domain name included in the certificate itself.
@@ -31, +31 @@

  Multi-domain certificates can secure multiple Fully Qualified Domain Names using a single
certificate. 
  Each certificate can simplify management and reduce costs given the right situation.
  
- "'Wildcard Certificates'"
+ == Wildcard Certificates ==
  The first type of multi-use certificate is the wildcard certificate. The name you embed
in a certificate must always follow the fully-qualified domain name (FQDN) format. If you
want a certificate for the Session Initiation Protocol (SIP) used by instant communication
servers in the VirtualSpaceShip.com domain, the name embedded into the certificate will be
SIP.VirtualSpaceShip.com. If you want a certificate for the email service, then you would
normally have to buy a second certificate with the second service name -- mail.VirtualSpaceShip.com
-- embedded into it.
  
  In addition, some secure service implementations require internal as well as external validation
and you use a different name for each; for example, InternalSip.VirtualSpaceShip.com  and
ExternalSIP.VirtualSpaceShip.com. In this case, you must have a certificate on each server
in the internal and external service to allow users to work unimpeded whether they are in
the office or on the road. This is the case for instant messaging infrastructures where you
want to ensure messages are encrypted whether they are internal or external. Note that servers
cannot include two certificates for the same purpose.
@@ -41, +41 @@

  For example, single wildcard certificate could easily support the following names and more:
www.VirtualSpaceShip.com, shop.VirtualSpaceShip.com, mail.VirtualSpaceShip.com, SIP.VirtualSpaceShip.com,
register.VirtualSpaceShip.com, and so on.
  In actual fact, the wildcard certificate supports the use of multiple sub-domain or prefix
names within the same certificate. Using a wildcard character as a placeholder in the domain
name embedded into the certificate makes the certificate much more versatile. In addition,
it can be applied to any number of uses since the wildcard character can represent any sub-domain
name. Because of this, wildcard certificates provide very good value for the cost.
  
- "'Multi-Domain Certificates'"
+ == Multi-Domain Certificates ==
  The second type of multi-use certificate is the multi-domain certificate. While the wildcard
certificate will include a special character for the prefix name, the multi-domain name provides
the ability to include multiple Fully Qualified Domain Names within the same certificate.
 However, unlike wildcard certificates which can support an unlimited number of prefix names
so long as the root domain name remains the same, multi-domain certificates will only support
the specific Fully Qualified Domain Names entered into the certificate. In most cases, multi-domain
certificates will support up to 25 or more different Fully Qualified Domain Names in one certificate.
  
  Multi-domain certificates include the standard Subject Name field which supports a single
primary service name, as well as an additional entry called the Subject Alternative Name field
which supports the additional service names. The SAN certificate can therefore be installed
on several servers and function properly to support internal/external service delivery.
@@ -55, +55 @@

  Multi-domain certificates are also useful for application service providers (ASP) who host
applications for multiple clients with each client using their own domain name. By using a
multi-domain certificate, ASPs can use a single certificate to support multiple clients. Note
that the site seal and certificate "Issued To" will only be for the primary domain name entered
in the certificate and will not include any of the other domain names. However, the certificate
itself will include all of the domain names that have been entered when the certificate was
purchased. 
  
  While multi-domain certificates are also useful when used to support unified communications
deployments, there are some caveats for their use:
- - Multi-domain certificates do not support use of wildcard characters.  For this reason,
sub-domain names must be added as a unique domain name entries in the certificate. Each time
a new domain name is added or an old one is removed the certificate must be updated and re-deployed
to each host server.
- - When hosting Web sites for multiple clients, ASPs should be aware that all domain names
appear in a multi-domain certificate. If the ASP does not want one site to seem as if it is
connected to another, then a different certificate type should be used.
-  Keep these caveats in mind when choosing a multi-domain certificate.
  
+  * Multi-domain certificates do not support use of wildcard characters.  For this reason,
sub-domain names must be added as a unique domain name entries in the certificate. Each time
a new domain name is added or an old one is removed the certificate must be updated and re-deployed
to each host server.
+  * When hosting Web sites for multiple clients, ASPs should be aware that all domain names
appear in a multi-domain certificate. If the ASP does not want one site to seem as if it is
connected to another, then a different certificate type should be used.
+ 
+ Keep these caveats in mind when choosing a multi-domain certificate.
+ 
- "'Wildcard vs. Multi-Domain Certificates'"
+ == Wildcard vs. Multi-Domain Certificates ==
  Organizations wanting to move to subject alternate name or unified communication certificates
should choose between the wildcard and the multi-domain certificate types. Table 1 outlines
the similarities and differences between the two certificate formats.
  
  Both certificate types offer several benefits and include several features. In addition,
both are available in full authentication format only. Domain-only authentication certificates
only require the validation of the domain before they are issued, and because of this, cannot
be used with multi-use certificates. Full authentication certificates require both the validation
of the domain itself and the validation of the business running the domain. Because of this,
full certificates are more trustworthy than domain-only certificates. This is another reason
the full authentication model is used for multi-use certificates. Keep this in mind as you
make your choice.
  
- "'Making the Selection'"
+ == Making the Selection ==
  Multi-use certificates were developed to provide multiple secure services originating from
a single IP address. To accomplish this, these certificates either add a subject alternate
name (SAN) field to the common single-use certificate or use a wildcard to replace the service
name in the certificate. Microsoft Exchange Server 2007 is an excellent example of this type
of requirement. The same external Exchange server can publish several different types of services:
Outlook Web Access, Outlook Anywhere Access, AutoDiscovery configuration information, and
more. Each of these services requires the publishing of its own name -- for example, OWA.VirtualSpaceShip.com,
Mail.VirtualSpaceShip.com, Autodiscover.VirtualSpaceShip.com --  ideally within a single certificate.
  
  Multi-use certificates reduce cost and simplify management by supporting the inclusion of
multiple names within the same certificate or the replacement of service names with a wildcard.
However, each multi-use certificate type should only be used in specific situations:
  
- * Wildcard certificates should be used when a single root name is used for all services
or where there is a single domain and only multiple sub-domains that cover all services. 
+  * Wildcard certificates should be used when a single root name is used for all services
or where there is a single domain and only multiple sub-domains that cover all services. 
- * Multi-domain certificates should be used when multiple root names are required for each
service.
+  * Multi-domain certificates should be used when multiple root names are required for each
service.
+ 
  Both certificate types offer reduced total cost of ownership (TCO) when they are deployed.
But obviously, both certificates only fit specific situations.
  
  Ideally, organizations would only use a single root name for all functions, but in most
environments, this is not possible. Many organizations use a least one public root name and
one private root name to segregate the internal from the external namespaces they work with.
In this case, only multi-domain certificates will work. But, if you only need a certificate
for external purposes and you only use one single public root name, then the wildcard certificate
is the certificate of choice.

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Mime
View raw message