San ssl

[ids-dave]

Has anyone used SAN SSL as their SSL solution for running multiple web sites (unique domains) ?

I'm running 14 websites on a single dedicated server using unique server config files and port numbers for each one. With Google's upcoming enforcement of every site having a SSL certificate I'm trying to figure out if this would be a viable solution.

After a lot of research, I am led to believe the SAN SSL certificate would allow me to run all of these sites with 1 server IP address and they would share port 443. Anyone know if this is indeed true?

Also, does anyone know if the Alpha certificate signing request (CSR) is compatible for a SAN SSL certificate ?


Thanks, Dave


Windows Server 2008r2
version 12.4.5.2
build 4770

[Lenny Forziati]

Re: San ssl

You have mixed 2 related but independent issues here:

1. Using a SAN to use a single certificate for more than one site
2. Running multiple sites on the same IP address and port

SAN Certificates
A Subject Alternative Name (SAN) certificate allows a single certificate to work for multiple hostnames. They are generally issued for several hostnames within the same domain name, not for unique domain names. These certificates will work in both the Alpha Anywhere Application Server and the Alpha Anywhere Application Server for IIS.

Use of a SAN certificate can simplify administration because it allows a single certificate to be used for multiple sites. At the same time, they also broaden your exposure because compromising the certificate would then compromise multiple sites instead of just one.

The tool in Alpha Anywhere to generate a Certificate Signing Request (CSR) does not have the ability to specify additional alternative names. You will need to use a different utility to generate your CSR.

Multiple sites
The Classic Alpha Anywhere Application Server will not be able to host multiple sites on the same IP and port. This is true whether your sites use TLS/SSL or are just plain HTTP. A SAN certificate will not enable this. You will need to continue to run multiple instances on differing IP/port combinations, or use the Alpha Anywhere Application Server for IIS.

Under IIS, you can run multiple sites (domain names) on the same port and IP address, and use Server Name Indication (SNI) to have IIS direct the requests to the appropriate site when using TLS/SSL. This will work with both individual certificates for each site as well as a single SAN certificate that covers all sites. This would all be part of your IIS configuration through Internet information Services Manager.

[ids-dave]

Re: San ssl

Thanks Lenny, the Server Name Indication (SNI) was the part I didn't notice until you pointed it out. Now it makes sense how this could be set up using the SAN/UCC approach

[jgrannis]

Re: San ssl

Actually Lenny, wildcard certificates are generally used for several hostnames with the same domain name.

SAN certificates are generally used when you need a certificate for multiple different domains and sub-domains. I used to work with one single SAN cert. that covered about 75 different domains and subdomains. (example: the certificate details for https://www.sephora.fr/)

EDIT: of course, if you can get away with just a wildcard cert., it should be A LOT cheaper.

[kkfin]

Re: San ssl

I'm running 14 websites on a single dedicated server using unique server config files and port numbers for each one.

I recommend you to use a web server ( I use Abyss) with reverse Proxy, SNI and Dual host support in front of AA Was. This makes configuration possible where you bind your AA Was to 127.0.0.1:85, 127.0.0.1:86 and so on. So Was is running localhost without SSL installed. The SSL is installed to web server running front of AA Was and .a5w pages are served using reverse Proxy feature in front end web server.

You can add also one more Reverse Proxy solution in front of web server for example CloudFlare and in this configuration you install free CloudFlare SSL (20 years ssl) to your front end web server and then you can also use free CloudFlare SSL or buy own in CloudFlare Proxy. Using CloudFlare and Abyss also makes possible to hide your servers actual IP which is important today. Abyss also makes possible to serve PHP, classic Asp, Asp.Net or any cgi solution together with AA Was from same domain.

[Lenny Forziati]

Re: San ssl

I recommend you to use a web server ( I use Abyss) with reverse Proxy, SNI and Dual host support in front of AA Was. This makes configuration possible where you bind your AA Was to 127.0.0.1:85, 127.0.0.1:86 and so on. So Was is running localhost without SSL installed. The SSL is installed to web server running front of AA Was and .a5w pages are served using reverse Proxy feature in front end web server.

You can add also one more Reverse Proxy solution in front of web server for example CloudFlare and in this configuration you install free CloudFlare SSL (20 years ssl) to your front end web server and then you can also use free CloudFlare SSL or buy own in CloudFlare Proxy. Using CloudFlare and Abyss also makes possible to hide your servers actual IP which is important today. Abyss also makes possible to serve PHP, classic Asp, Asp.Net or any cgi solution together with AA Was from same domain.

While Abyss, Apache, nginx, etc. work in this type of configuration, using the Alpha Anywhere Application Server for IIS tends to be much simpler and significantly easier to configure and administer. Because Alpha Anywhere is directly integrated into IIS, you do not need to run separate Application Server instances with unique configuration files at all. There is no need to reverse proxy any communication which means it is more efficient, and everything can be administered in a single and consistent UI. IIS can also serve PHP, classic ASP, ASP.Net and others.

[kkfin]

Re: San ssl

While Abyss, Apache, nginx, etc. work in this type of configuration, using the Alpha Anywhere Application Server for IIS tends to be much simpler and significantly easier to configure and administer. Because Alpha Anywhere is directly integrated into IIS, you do not need to run separate Application Server instances with unique configuration files at all. There is no need to reverse proxy any communication which means it is more efficient, and everything can be administered in a single and consistent UI. IIS can also serve PHP, classic ASP, ASP.Net and others.

In fact unique configuration files makes all so easy. Make one and copy and change. They are the best part of WAS. Easy to maintain and easy to change.

[Lenny Forziati]

Re: San ssl

Actually Lenny, wildcard certificates are generally used for several hostnames with the same domain name.

SAN certificates are generally used when you need a certificate for multiple different domains and sub-domains. I used to work with one single SAN cert. that covered about 75 different domains and subdomains. (example: the certificate details for https://www.sephora.fr/)

EDIT: of course, if you can get away with just a wildcard cert., it should be A LOT cheaper.

My apologies Jeff (and others), I mixed some opinion with fact. I will clarify:

A SAN certificate allows the for the use of a single certificate for several hostnames. These are not in any way required to be hosts within the same domain name. However because they allow a single certificate to be authoritative for several domain names, they allow the potential for identities to be mixed. This is particularly true when the domains are for different entities. While it is possible to have a certificate issued that would be valid for both JeffGrannis.com and LennyForziati.com, such a certificate would allow me to impersonate Jeff, and Jeff to impersonate me. I feel such a certificate is a poor practice and creates an increased security exposure that is unnecessary. However a certificate that is for server1.alphasoftware.com and server2.alphasoftware.com is less of a risk because it only allows alphasoftware.com to act as alphasoftware.com. This does still carry increased exposure though because the certificate falling into the wrong hands allows the impersonation of multiple servers.

A wildcard certificate allows the use of an unlimited number of hostnames at a single level within a given domain name. So *.alphasoftware.com will allow www.alphasoftware.com and foo.alphasoftware.com but not server1.test.alphasoftware.com. This is very convenient for a server administrator with many hosts to secure. It is also a significant risk because compromising the certificate will compromise every single host secured with it, and even hosts that don't exist yet. For example, someone that gains unauthorized access to *.alphasoftware.com doesn't need to also break into www.alphasoftware.com because they could instead set up somehostthatdoesntexists.alphasoftware.com and use it to spoof our website.

Based on the above, my personal opinions are:

• Wildcard certificates should be avoided if at all possible. Where they are used, their use should be tightly controlled and severely restricted (e.g. don't use *.yourdomain.com on an internal system and also give it to a hosting provider to use on your behalf).
• If you want to provide services for multiple hosts within a single domain using a single certificate, strongly prefer a SAN certificate to a wildcard certificate in order to limit exposure.
• Don't use a SAN/UCC certificate for domains not owned/operated by the same entity. If you are providing hosting services for customer1.com and customer2.com, get separate certificates for each customer.
• Before using either a SAN or wildcard certificate, strongly weigh the increased ease in administration against the increased risk of exposure. Eased administration does of course carry some potential security advantages as well, but there are a whole array of security tools available for key management to at least partially address the administration burden without increasing the exposure in the ways that SAN and wildcard certificates do.
• Sephora.fr, mentioned by Jeff, is a great example of what NOT to do. If you visit https://www.sephora.fr, you are immediately redirected to the insecure http://www.sephora.fr instead at a time when there is a hug industry-wide push to use encryption for all web traffic. Also the server supports TLS 1.0 and a number of weak ciphers. Things then get much worse if you visit https://sephora.fr (omitting the www as is commonly done by users, and which cannot be prevented by server operators). That site responds with a certificate for webmail.domainoo.com instead and is horrendously insecure (allows TLS 1.0, cert is using the old SHA1 signature algorithm along with a weak 1024 bit key). I will give them partial credit for how they use the SAN certificate though - all of the hosts seem to at least be Sephora-owned domain names but it looks like some of them are for non-production (e.g development) systems which is a poor practice.

[jgrannis]

Re: San ssl

Usually any serious Certificate Authority will only issue a SAN certificate covering the list of domains that the single entity can prove own/control. The proof of control of a domain that I've most recently seen the CA's ask for is to add a special DNS record for the domain. It seems like a pretty good verification method on their part to prevent impersonation because it is hard to add a DNS record for a domain you don't control/own.

In any case, thanks for the information.

[kkfin]

Re: San ssl

When you see SSL lock icon in browser you think that traffic is encrypted and connection is secure. But it is secure just if you know the configuration has been done right.

You can understand this if you think two separate physical servers with different IPs. Server one and two. Server two has the actual data and server one is reverse proxy (or load balancer). Server one has SSL certificate but server two not. Server one is the front end server.

When connected to the site you connect to server one and you see in browser window SSL lock icon but data served between server one and server two is not under SSL. Server one can be in Boston and server two in Sydney.

SSL does not mean anything if not done right. And as a user you do not know how setup is done.

[Lenny Forziati]

Re: San ssl

Yes, any decent CA will verify the identity/control for the hostname(s), and any less-than-decent CA will have their root certificate no longer trusted - case in point being Symantec. Verification varies across vendors and even within a given vendor's product lines. I wasn't suggesting it would be easy for me to get a certificate in your name. Rather, with your cooperation I could get a certificate in your name as well as my own. Someone could then steal "my" certificate and also impersonate you. Or you and I could disassociate yet I'd still be able to act in your name.

And yes, there are ways to revoke a certificate. And for that matter, every certificate should have the SAN field populated even if it is not sold as a "SAN certificate". What I am trying to make clear though is the increased exposure that goes along with various certificate types. I think they are important considerations to be aware of.