These days, the use of SSL has become much more common. Traditionally, it was mandatory to have your website setup with a unique IP in order to use an SSL certificate.
More recently, SNI based SSL has become available and it has caused some confusion. In this post, I’m going to discuss the topic and hopefully give you enough information so that you can choose whats the best option for you.
The mother of all code camps, the Silicon Valley Code Camp took place a couple of weeks ago. As always, the organizers did a fantastic job and this year’s event was even bigger than last years. From ASP.NET to SQL to Node to Hadoop, there was something for everybody. With over a hundred sessions available, five thousand developers took over the Foothill College campus for the weekend.
The mother of all code camps is only weeks away.
Attendance for the Silicon Valley Code Camp is usually over 5,000 people and this year we are expecting even more. As long time supporters of code camps, user groups, and the ASP.NET community at large, I can tell you this is the big one.
Early last month, Michael Phillips wrote about our Git support. As you may know, you have a Git repository included for free with your Everleap account. So if you’re not using TFS for your site, I would urge you to at least use Git. If you’re not familiar with Git, take a look at this video to help you get started.
Times have changed. While VPS, traditional and dedicated hosting solutions still have some use cases, the truth is, it’s 2014 and those legacy solutions are losing relevancy by the hour. Today’s cloud – the real cloud – is a much better solution.
As with anything however, we need to adjust. Take for example the use of HTTPS. If you’re using an SNI SSL solution, you’re in the clear. The security information for your cert lives in the load balancers and is available to all of the web servers, so there is nothing else you have to do to use HTTPS.
However, if you are using a unique IP-based SSL solution, there are some things to consider. In this article I’m going to cover a few of the key points.
In the old days, when there was an update, you felt like you just got a brand new gadget. Fresh, new, cool stuff to play with. These days, the cadence of updates is so fast, you can’t expect open the box and and find a drone every single time.
MVC 5.2, WebAPI 2.2, and Web Pages 3.2 have been updated. You can check MSDN for the details, but other than some improvements to attribute routing, there isn’t anything to plan a celebration for.
There are two primary reasons to configure your website to use ASP.NET Custom Errors. The first being to provide your end users with a polished experience, even when things don’t go as expected. Nothing says “this site was slapped together” more than the generic 404 page issued by IIS or the 500 series yellow screen of death the ASP.NET Engine generates.
There are also security concerns when rendering verbose error messages to your users browser. There is no need for the world to know anything about the inner workings of your application. In fact if your website does expose verbose error data, you likely will not have a shot at becoming PCI compliant.