Securing all Jetendo Site Managers with a wildcard SSL certificate

  Follow me: Follow Bruce Kirkpatrick by email subscription Bruce Kirkpatrick on Twitter Bruce Kirkpatrick on Facebook
Thu, Oct 31, 2013 at 2:00PM

There is new domain alias support in Jetendo now, which allows a specific site to return the same content for multiple domains.  Generally this is bad for search engine optimization since it creates duplicate URL for the same content.

I'm thinking one of the best uses for domain aliases is to allow the site to be accessed with a domain that has SSL required with a wildcard ssl certificate for just the manager or secure transactions.   This will also allow us to setup secure domains before a client has bought a domain.   A lot of times, a web site that is being developed is put on a temporary domain because there is already a live site on the real domain.  You probably wouldn't want to buy a secure certificate for your test domain, so you'd end up with inferior security while testing.   It would be better if a site was secure during development in addition, so this feature will allow this to happen.

I could also prevent robots / public from accessing the SSL domain by requiring the wildcard ssl domain to have a login and separate robots.txt file. 

Features like tinymce html editors and fields that require a url to be entered can lead to having the test domain / non-primary domain get inserted into the database.  However, Jetendo CMS already prevents the current domain from being saved into the database.  It cleans the posted form data so it changes https://testdomain.corporatedomainexample.com/ to be just / automatically.  This makes it very fast to go live when your project is approved.  You don't have to fix a bunch of incorrect URLs or worry about duplicate content mistakes as much.

A wildcard domain and ssl certificate would work like this:

https://client1.corporatedomainexample.com/
https://client2.corporatedomainexample.com/ 
etc...

You can do that for $60 per 2 years with startssl.com's organization validation product. (not green bar).  Or up to $150 per year with comodo positive ssl wildcard ceriticate.

The wildcard domain will show registered to a single company, such as Far Beyond Code LLC on the domain whois and certificate details if the user looks at them.   If you partner with other web developers and you want them to be able to white label Jetendo for their customers, you need to have your business partner buy a separate wildcard certificate and give all their client domains a separate static ip.  As long as that is done, it is easy to setup multiple wildcard certificates for other companies you partner with.

The domain's dns has to be able to push ANYTHING.domain.com to a specific ip for it to work, so you should consider using a domain that doesn't interfere with your primary corporate domain for the wildcard certificate.  For example, I don't want to put all my clients on *.farbeyondcode.com.  I'd rather create a separate domain for this purpose instead.

Getting a wildcard green bar secure certificate isn't possible.  You have to individually add the domains you want to use to an EV certificate for them to work.  If you don't add clients very often, that might seem reasonable, but I'd rather not have to reinstall certificate for each new client and that may not be free.  It also costs at least $400 the first time I get one with startssl because you need to prove your identity with a passport and other info, but it will last 2 years and it provides a good boost in revenue according to research on behavior of users using ecommerce sites, so it may be worthwhile to consider for some businesses.

Why use SSL on sites that don't have important data?

The main reason to use SSL on all web sites is that your users might be using the same password they use for other more sensitive accounts when they login to your service.  If your service doesn't protect that password appropriately with SSL and hashing/salting, then you're putting your users at risk with man in the middle attacks that can occur on untrusted public networks.  Untrusted networks, 3g/4g+, unsecured wifi, are all dangerous for people sending passwords and other sensitive data over plain text.  

SSL increases confidence in your brand a small amount.   A user may assume that the information was received in a safe way, even if they don't fully understand the details.  My company sites run on SSL already with free startssl.com certificates because I want to lead by example and it's free to do this currently, so it is just lazy to not use SSL certificates for every web site.  The Jetendo CMS Open ID authentication system also is secure because the communication with Google/Yahoo/AOL is through SSL.  Google Adsense even supports SSL now, so you don't have limitations anymore where a content portal can't run SSL because of banner advertising requirements.  

You can also prevent a lot of client-side attacks like javascript that gets embedded that points to an untrusted domain.  It is less likely that dangerous javascript can be installed on a domain's public pages with SSL enabled.  It won't even be able to execute because the browser blocks non-ssl content automatically.  Most of the big third party apis and widgets support SSL too including youtube, disqus, twitter, facebook, google, yahoo.  SSL also protects you from third party api security mistakes better since they might try to do non-ssl operations sometimes, which will be disabled. 

Having the entire internet running SSL should be your goal if you care about security.  Google cares a great deal about that, and made SSL not only the default for their logged in users, but also made SSL faster then regular HTTP by creating the SPDY protocol for apache and chrome.  Other browsers and web servers have added support for it too including nginx, firefox and internet explorer 11, so there is no reason not to be using SPDY and SSL now. 

Jetendo fully supports this feature now

11/10/2013 Update: There is now a field called "SSL Manager Domain" in the Jetendo CMS Server Manager that lets you specify an SSL domain that will override the site's regular site manager login.  There is also an option in Application.cfc that lets you set a default SSL Manager domain, so the system can automatically prefill the SSL Manager Domain for new or existing sites.   The SSL Manager domain can be any valid domain, it doesn't have to rely on a wildcard SSL certificate.  The user will be automatically redirected to the SSL domain once this is setup, so that they never enter their password or sensitive information without an encrypted SSL connection.  Nginx was also updated to be able to server a robots.txt that blocks all robots if they visit the site via the SSL domain.   Also, forms posted with the SSL domain remove all links that point to the domain automatically, so you don't accidently create links to the SSL domain in your content.


Bookmark & Share



Popular tags on this blog

Performance |