Tag: HTTP

Creating a broadly compatible, modern SSL certificate with Active Directory Certificate Services

After recently hitting the default two year expiration point with our SharePoint development environment’s AD CS-issued SSL certificates, I set about updating that environment with a new five year template. I took this opportunity to see if I could make it as good as possible without breaking compatibility with anything. I will discuss some of these compatibility issues along the way. I will also make the certificate exportable, make sure it’s using the SHA256 hash (SHA1 will be deprecated in the near future), change the Certificate Authority (CA) configuration so that HTTP Distribution Points will be contactable from “outside the network”, and set permissions on the template in a way that it will be generally usable.

Steve Peschka tackled some of these basics about 18 months ago, but as he notes, his posts covers the simplest updates you can make. I think a few other options are worth considering. I don’t pretend to know all that there is to know about Active Directory Certificate Services (AD CS), or PKI in general, but I do think we can advance considerably beyond the default with a few changes. This is not a well-documented subject, so I hope to pull a few disparate resources together and propose an improved template. If you think anything here can be improved further, please post in the comments and I’ll try to incorporate that feedback.

Continue reading “Creating a broadly compatible, modern SSL certificate with Active Directory Certificate Services”

BLOB Cache, HTTP 304 Results and F5/Refresh

A few months ago we launched a new website on SharePoint 2010. One of my main foci on the project was performance and caching is one of the most effective ways to achieve that for a WCM solution. We enabled Output, Object and BLOB caching,  configured exclusions as necessary and were quite pleased with the results, especially since issues with BLOB Caching in 2007 have been resolved in 2010.

A few weeks later I was demonstrating these approaches when it was pointed out that we were getting lots of 304 responses. They occurred with each request for a previously-downloaded BLOB Cached asset (more detail added below). Basically, I overlooked the max-age attribute in the BLOB Cache web.config settings. By default, this attribute isn’t present in the web.config file and I simply missed it. Adding this attribute eliminated the 304 results and the caching configuration was complete. Or so we thought.

Edit to provide more detail on the 304 status and Max-Age
A 304 response is a File Not Modified status (not an error), in this case indicating that the browser is making (potentially) surplus checks for each previously-downloaded BLOB Cached file. The max-age attribute gives the file a lifetime in the client’s browser cache in order to reduce these update checks. To be clear, the BLOB Cache stores large objects on web servers to reduce database traffic, but those objects can be served with a max-age attribute that will determine the object’s lifetime in the client’s browser cache. A max-age value of “14400” means that browsers will cache the file for four hours before checking for an update. This means that updates to BLOB Cached content may become stale if this value is set too high. A common value would be “86400” (24 hours) but we were satisfied with the balance at four hours. In our case, making this update has not yielded a perceptible increase in performance with the current levels of traffic, but it’s the sort of thing you want to set appropriately in order to optimise things and to allow the environment to scale.

Continue reading “BLOB Cache, HTTP 304 Results and F5/Refresh”