Tales from Easement Acres
I neglected to mention that we got a new dog. It’s a puppy rescue. It’s also a Feist. It’s also ornery and destructive. I hate dogs that need to be busy.
But it’s also, like most dogs, sweet and loyal. It’s already demonstrated some protective behaviors, and is wary of novelty, rather than immediately accepting a la whippets.
Two is the critical mass for canines. Our family is now stable under the laws of density.
–Simon
Last month marked the official anniversary of Liz and my iron-clad bonds of matrimony. Or, in this case (being year 7), copper, according to the traditional anniversary gift theme.
As such, I was tasked to find the appropriate copper gift. And I decided upon something pseudo-useful and humorous. No, it wasn’t piping. It was a giant copper cock!
Also known as a rooster, of course. To fit the country theme of the below garden, or something. Okay, so it’s just kinda cool to have a weathervane and I hoped she’d like it.
She did. Here’s me testing it’s accuracy with a sole digit raised aloft to the heavens–or valiantly proclaiming something (“Aeris Amare!”):
–Simon
First off, the car broke. Again.
As it was still under warranty, we took it back to the dealership. Through constant harassment, I eventually discovered that the dealership could only bill 2 hours of labor per day to the manufacturer, and as the job would require 6 hours, we wouldn’t receive the car back before vacation started.
The vacation miles would also put the car much closer to being out of warranty, and the vehicle’s track record made this prospect unsettling. Liz debated (or I think she debated), then traded the car in and bought a brand new Subaru Ascent. It’s dark reddish brown. I christened it The Coffee Bean.
So it was that we broke in a new family car with a roadtrip to Orlando.
As it turns out, Orlando and Universal Studios is expensive and busy and not relaxing in the slightest. But I hope it made some memories:
We listened to Harry Potter audiotapes down and back. I’m glad to be home.
–Simon
Okay I admit, I didn’t make that joke up. But I like it so I’ll “repost” it.
My recent post on cursive got me thinking about text again. In it, I briefly mentioned the common knowledge that sans-serif fonts were supposedly easier to read on a digital medium, whereas serif fonts were better in their printed form. Of course, the CSS class I had taken once also touted an ideal single-line character limit as the easiest to read. I was skeptical at the time, and talked about how to override the default WordPress line limit. Now, staring at what I consider to be a juvenile-looking default sans-serif font, I decided that needed changing too. In short–the Internet is wrong and I have to take matters into my own hands.
And so, you might have noticed that the fonts on this site are different now. After some trial and error, I decided upon “Freight Text”, based on nothing more than the fact that I found it the most visually pleasing.
I have no idea who develops fonts and what’s involved with the process of their standardization. That’s a topic for another day’s adventure through the interwebs. But I found this brief description:
Phil’s Fonts evolved from one of the most well known and respected photolettering studios in the industry – Phil’s Photo. We carry on the traditions and standards established by its founders. As the state of typography changes in the digital era, Phil’s Fonts continues its love affair with beautiful faces, making fine typography available to artists and communicators around the world.”
Apparently there’s some studio that makes these and people decide whether or not to adopt them? Whatever
Regardless, if you don’t have the font installed, your browser will revert to its default serif font:
{
font-family: “Freight Text”, serif;
color: #000000;
}
And that’s it, really. I changed the CSS for a number of elements. Sure, fonts might be a pointless argument, but in this specific instance, I’d rather choose a more sophisticated-looking variant over its overly-simplified modern counterpart.
–Simon
The burdens of SSL certificate maintenance to a website admin are, I’m guessing here, universal. Even after the process of acquiring one is complete, the installation and configuration can be somewhat daunting. And if this were a one-time deal, it’s be far more tolerable, but as the certificates regularly expire, it’s a constant hassle. So I’ve bounced between certificate authorities as my own circumstances, as well as those of the industry, have changed.
I began this site with with a company called StartSSL. At the time, I found them efficient, affordable (as in–free), and with an easy to use website. My user ID was assigned via browser certificate (as opposed to the username/password method), and on their dashboard I could mint on-demand website and email certificates with standard WHOIS-based domain name validation.
But when I went to renew one day, I found the site to no longer be functioning properly. The basic operations to which I was accustomed had vanished, and my attempts at minting new certificates resulted in incompatible file types. I searched for info, but as the service was free, it was hard to come by. Further research revealed that they had been acquired, and shortly thereafter made the tech news for their new parent company’s bad security practices (and secret acquisition). Ultimately, they got themselves blacklisted by browser vendors and once my certificates expired, I would not be able to use StartSSL as a CA.
By this time, however, the EFF’s certificate project had launched and was gaining traction. The service, Let’s Encrypt, boasted hassle-free and automatic domain-validated SSL certificates. The best part was that my server’s manufacturer released an update which integrated the process into their stock software. With just a few selections, I could request a certificate, then be issued one with no further input on my part to install it. And even better, the service would reissue automatically prior to the certificate’s expiration (which was limited to 90 days, but that’s not a bother when they reissue on their own). I made the switch.
Then I received an email. The domain validation system used (a variant of the HTTP file-based verification method–more on this in a bit), was being sunsetted due to security vulnerabilities. I checked with my server manufacturer’s forums, but couldn’t find any information on how to change the default verification method. So with 30 days of lead time, I looked into finding a new certificate issuer.
I would have thought that because of the EFF’s efforts, certificates would have become very affordable. And they are, but you have to dig, because the majority of advertised products are intended for business and/or ecommerce use. Securing a certificate for a personal non-business home-based server proved to be somewhat trying, but I did eventually find such a line of products: COMODO’s PositiveSSL certificates.
These certificates are domain-validated only, meaning to acquire one you only have to prove you control the domain. This is the only type I’ve ever used, as their application is rather low-risk, this being a blog. Their price point is due to the ability to automate the process, and while it offers the same level of encryption as any industry-standard certificate, it’s a very basic level of authentication. Here’s Wikipedia’s explanation (https://en.wikipedia.org/wiki/Domain-validated_certificate):
“The sole criterion for a domain validated certificate is proof of control over whois records, DNS records file, email or web hosting account of a domain. Typically control over a domain is determined using one of the following:[3]
A domain validated certificate is distinct from an Extended Validation Certificate in that this is the only requirement for issuing the certificate. In particular, domain validated certificates do not assure that any particular legal entity is connected to the certificate, even if the domain name may imply a particular legal entity controls the domain.”
But alas, with COMODO, this was my first encounter with a certificate-signing request. With StartSSL, the service generated the public/private key and installed it into my browser, which then required me to export the file and import it into my server. I’m assuming that’s okay, but it is placing a lot of trust in the certificate issuer, as in theory they’d have/had access to the private key. A certificate-signing request, on the other hand, eliminates that security hole.
The process is as follows: the server creates a certificate/private key pair, wherein the certificate is signed by the private key (standard procedure). The certificate is then exported, which in turn is uploaded to the CA. After validation, the CA then signs the certificate with their own certificate’s private key (the intermediate certificate), and then provides that now-signed certificate alongside the signing intermediate certificate. Both are uploaded to the server, along with the original private key. The three files now supply encryption and identity validation (via the certificate chain path through the intermediate certificate).
It sounds complicated, but from the user end it’s mostly automatic. The burden lies in the validation process.
As stated above, domain validation is merely the process of confirming that the requestor actually controls the domain to which they’re requesting a signed certificate. And, as Wikipedia explained above, COMODO chose to do this in one of 3 ways:
Uploading the certificate files was pretty straightforward after that, and a quick setting change switched it over. I’ve kept my Let’s Encrypt certificate just to see what will happen with the renewal, but if that fails and it expires, I’ll still be good now with a 2-year COMODO one. Hopefully when renewal time comes up for that, I’ll have this article available to remind me how I did it. And…if anyone else besides myself ever discovers this article and finds it useful, that’s cool too.
–Simon