Bi-monthly SSL certificate update

Blog

About once every other month I’ve accumulated a list of SSL certificates that must be renewed. Now; all experience has show that it’s a good idea to verify that the service in question is actually using the renewed certificate. I’ve updated the wrong configuration file; I’ve forgotten to restart services to re-read the certificate and I’ve had services claiming to have read the new configuration, but in reality still running with the old certificate. As a result I’ve picked up the habit of always checking that the new certificate is actually the one being used. For HTTPS this is simple enough; all browsers I use have a really simple way of checking the expiry date of a site certificate. But what about when you’re using SMTPS, IMAPS or POP3S (or SMTP, IMAP or POP3 with STARTTLS). I know there’s a way, but I always forget, and have to ask Google. Well; not any more: Here’s how to fetch the certificate for such services:

IMAPS

echo | \
openssl s_client -connect imap.example.com:993 -crlf 2>&1 | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cert

IMAP with STARTTLS

echo | \
openssl s_client -starttls imap -connect imap.example.com:143 -crlf 2>&1 | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cert

POP3S

echo | \
openssl s_client -connect pop3.example.com:995 -crlf 2>&1 | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cert

POP3 with STARTTLS

echo | \
openssl s_client -starttls pop3 -connect pop3.example.com:110 -crlf 2>&1 | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cert

SMTPS

echo | \
openssl s_client -connect smtp.example.com:465 -crlf 2>&1 | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cert

SMTP with STARTTLS

echo | \
openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf 2>&1 | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cert

Once you’ve got the certificate (the above commands will store it in a file named cert in the current working directory) use the following command to extract the expiry date:

openssl x509 -in cert -noout -enddate

Sample output

notAfter=May 13 21:22:55 2012 GMT

Simple as that…

The Unbearable incompetence of GoDaddy

Blog

I moved the db.org domain to GoDaddy back in 2005/2006 in a desperate attempt to escape the predatory “competitive practise” of VeriSign/Network Solutions and the limitless incompetence of register.com. At the time this worked out great, and why wouldn’t it. It’s not rocket science!

I don’t ask a lot of a registrar. Just make sure the TLD publishes NS records for my domain along with any necessary glue records. And of course a way to modify said records. Sounds simple enough…

Sadly something has gone terribly wrong at GoDaddy since the last time I had to deal with them. Have a look at their web site. Where one would hope to find helpful technical information, you get pictures of b-list celebrities. Where one would hope to find tools for domain registration management, you get “special offers”, discounts and deals. Where one would hope to find customer support contact information, you get the always present, never ending drivel of “Bob Parsons, CEO”.

All I wanted to do was change the NS records for botnegaten.org. Not a lot to ask of a domain name registrar I thought. How wrong I was…

From: bob@db.org
To: support@godaddy.com
Subject: Setting nameservers for domain
Date: 2009-12-21 09:05 +0100

I'm trying to set:

a.ns.db.org
b.ns.db.org

as nameservers for botnegaten.org, but I keep getting the following
error message for both nameservers:

"Nameserver not registered."

What am i doing wrong?
From: donotreply@godaddy.com
To: bob@db.org
Subject: Request Received - Incident ID 8026729
Date: 2009-12-21 09:07 +0100

Your question has been received. You should expect a response
within 24 hours.

This is your Incident ID: 8026729

Huh; the form where I filed the incident promised me a reply within 4 hours. Clever trick really; as they sent me the above auto-reply in just a few minutes, they have technically upheld their promise of a response within 4 hours…

From: support@godaddy.com
To: bob@db.org
Subject: Update [Incident ID: 8026729] - Support Question
Date: 2009-12-21 14:00 +0100

Dear B. Johannessen,
Thank you for contacting online support.

You are not required to register hosts, but if you intend to set up
your own Domain Name Server (DNS) service, you can register
your own hosts. You can enter up to 13 hosts, depending on the
maximum number of hosts the top-level domain (TLD) registry
allows.

WARNING: Unless you have a thorough understanding of this
process, we recommend that you do not use this feature.

To Register Your Own Hosts
Log in to your Account Manager.
In the My Products section, click Domain Manager.
Click the domain for which you want to create a host.
In the Host Summary section, click the add hyperlink in the header.
In the Host name field, enter the host name you want to register.
NOTE: Do not enter "www" as part of your host name.

In the Host IP fields, enter the IP address(es) you want to add to
the host.
Click OK.
It takes 4 to 8 hours to register hosts for .COM and .NET domains
and 24 to 48 hours for all other domain extensions.

Thank you,
Jennifer T.
Online Support

Thanks “Jennifer”, I’m sure you’re right, but that’s not what I asked. Apparently support@godaddy.com is manned by the trained monkey squad, and the monkey training leaves a bit to be desired! Let’s see if we can get this escalated to someone with above room-temperature IQ (or a least a basic understanding of the DNS).

From: bob@db.org
To: support@godaddy.com
Subject: Re: Update [Incident ID: 8026729] - Support Question
Date: 2009-12-21 14:22 +0100

Please, please, PLEASE escalate this to someone qualified to do
something other then return a pre-written reply!

I'm trying to set the nameservers for botnegaten.org to A.NS.DB.ORG
and B.NS.DB.ORG, but when I do so, I get an error message saying
"Nameserver not registered." for both values.

My father always says you should hope in one hand, spit in the other and check to see what hand ends up the fullest (sounds a lot better in Norwegian, but you get the idea). So; at this point I’m sitting back hoping for intelligent life at GoDaddy support…

From: donotreply@godaddy.com
To: bob@db.org
Subject: Request Received - Incident ID 8026729
Date: 2009-12-21 14:23 +0100

Your question has been received. You should expect a response within
24 hours.

This is your Incident ID: 8026729

Good to know…

From: support@godaddy.com
To: bob@db.org
Subject: Update [Incident ID: 8026729] - Support Question
Date: 2009-12-21 19:13 +0100

Dear Bob,

We will need to see the exact error that you receiving when trying
to change the nameservers. The term screen shot refers to
"grabbing" a still image of the contents of your computer monitor
that can be saved as a graphic file and printed, faxed, or emailed.

Screen shots are very helpful in explaining what you are seeing on
your computer when working with customer support. It is often
easier for you and for the support representative if you take a
screen shot of what you are seeing and simply send it in.

Here is a quick step by step on how to do it:

...
...
...

Regards,
Alfonso P.
Online Support

I’ve heard a picture is worth a thousand words, but this is ridiculous. Guess I was mistaken about who’s manning support@godaddy.com. The untrained monkey squad is clearly taking over!

From: bob@db.org
To: support@godaddy.com
Subject: Re: Update [Incident ID: 8026729] - Support Question
Date: 2009-12-21 20:54 +0100

I've told you what "the exact error" is two times already, but if
you find pictures easier to understand I guess that's my problem.

Please find attached a screenshot showing the "Nameserver not
registered." message in question.

Problem description: I'm getting this message when trying to
change the nameservers for botnegaten.org to A.NS.DB.ORG
and B.NS.DB.ORG.

Is it acceptable to include the problem description in plain text,
or would you prefer I make a screenshot of that too?

Attachment: godaddy.jpg

Wait for it…

From: donotreply@godaddy.com
To: bob@db.org
Subject: Request Received - Incident ID 8026729
Date: 2009-12-21 20:54 +0100

Your question has been received. You should expect a response
within 24 hours.

This is your Incident ID: 8026729

Another fine answer. To bad it’s not an answer to anything I’ve asked..

From: support@godaddy.com
To: bob@db.org
Subject: Update [Incident ID: 8026729] - Support Question
Date: 2009-12-22 04:24 +0100

Dear Bob,

Upon review, neither of the nameservers given are
registered at this time. You would need to register them
and then add them to your domain in order for it to work.

You can setup custom nameservers for your domain
name by using the following instructions.

* Select "Domain Manager" from the gray "My Products"
drop down menu on the left side of the page.
* From the domain name list click the blue link that is
the domain name in question.
* Click the "Edit" link under "Host Summary" on the
lower left hand side of the screen.
* Enter the appropriate Host Names and IP Addresses
for the nameservers you wish to create.
* Click the Orange "OK" link to save the changes.

Note that you must still change the domain name's
nameservers to point a domain name to any custom
nameservers that you create.

To change the nameservers for a domain:

* Check the box to the left of any domain names that you
wish to change the nameservers for.
* Click on the "Nameservers" button in the row of buttons
just above the list of domain names.
* Under the "Custom Nameservers" tab you will be able to
enter the necessary nameservers for the domain name(s).
* Click the orange "OK" button on the right hand side of the
page to save the changes.

Please allow up to 24-48 hours for the changes made to
the domain name(s) to take effect.

Please let us know if we can assist you in any other way.

Sincerely,

Stacey P.
Online Support Team

I’ve heard that given enough monkeys and enough typewriters, eventually one of those monkeys is bound to type out something useful. Clearly this is the strategy used in the GoDaddy support department. Hey guys! You need more monkeys!

From: bob@db.org
To: support@godaddy.com
Subject: Re: Update [Incident ID: 8026729] - Support Question
Date: 2009-12-22 04:47 +0100

I ask once again that you escalate this to someone with a
clue. The procedure you're suggesting will only allow me
to register namservers in the botnegaten.org domain. I'm
trying to use nameservers in a *different* domain.

Once again; I'm trying to use a.ns.db.org and b.ns.db.org
as nameservers for the domain botnegaten.org. Using the
procedure you suggested would allow me to register
a.ns.botnegaten.org and b.ns.botnegaten.org for use as
nameservers, but this is *not* what I'm trying to do!

Either I'm missing some essential peace of information,
or it's not currently possible to preform this operation
using your web-interface.

Please see that this is escalated to someone capable of
understanding the problem!

    Bob

Back to watching paint dry…

Breaking Bing Cashback

Blog

Apparently Samir Meghani at the Bountii Team Blog decided on surrendering to Microsoft and Bing Cashback. Sadly for Microsoft, their lawyers was too dumb to make sure the same content was removed from Microsofts own “search engine” cache.

http://cc.bingj.com/cache.aspx?d=4879267570255838&mkt=en-CA&setlang=en-US&w=90157511,9ea4ebc5

Update: Microsoft removed it from Bing cache

Just in case they should grow a clue, here’s the description of the technical problem that Microsoft, in its infinite wisdom, decided to correct with lawyers instead of software engineers:

I’ve never bought anything using Bing Cashback, but the balance of my account is $2080.06. Apparently, I placed two $1 orders on January 24th of this year, and spent another $104,000 on October 24th. Let’s see how these transactions might have “accidentally” got credited to my account.

First, we need to try to figure out how transactions get into Bing Cashback. Microsoft posted some documentation here. The explanation of how a merchant reports transactions to Bing starts on page 20. Merchants have a few options for reporting, but Bing suggests using a tracking pixel. Basically, the merchant adds a tracking pixel to their order confirmation page, which will report the the transaction details back to Bing. The request for the tracking pixel looks something like this:

https://ssl.search.live.com/cashback/pixel/index?
jftid=0&jfoid=$ORDERID&jfmid=$MERCHANTID&m[0]=
$ITEMID&p[0]=$PRICE&q[0]=$QUANTITY

This implementation, while easy for the merchant, has an obvious flaw. Anyone can simulate the tracking pixel requests, and post fake transactions to Bing. I’m not going to explain exactly how to generate the fake requests so that they actually post, but it’s not complicated. Bing doesn’t seem to be able to detect these fake transactions, at least not right away. The six cents I earned in January have “cleared,” and I’m guessing the remaining $2080 will clear on schedule, unless there is some manual intervention.

Even if Bing detects these fake transactions at some point in the future, the current implementation might have another interesting side effect. I haven’t done enough work to say it with confidence, but a malicious user might be able to block another user’s legitimate purchases from being reported correctly by Bing (I only tried this once, but it seemed to work). Posting a transaction to Bing requires sending them an order ID in the request. Bing performs a reasonable sanity check on the order ID, and will not post a transaction that repeats a previously reported order ID. When a store uses predictable order ID’s (e.g. sequential), a malicious user can “use up” all the future order ID’s, and cause legitimate transactions to be ignored. Reporting would be effectively down for days, causing a customer service nightmare for both Bing and the merchant.

Based on what I’ve found, I wouldn’t implement Bing Cashback if I were a merchant. And, as an end user and bargain hunter, it does not seem smart to rely on Bing Cashback for savings. In our next blog post, I’ll demonstrate some other subtle but important reasons to avoid using Bing Cashback.

WordPress and duplicate content

Blog

WordPress has come a long way with regards to it’s default URL scheme. I needed only two minor tweaks to make me completely happy with it. The first one really isn’t WorPress’ fault either. I really dislike publishing the same content on http://host.example/... and http://www.host.example/..., but at the same time I want to be able to accept incoming links with both hostnames. The solution is pretty well known, though I choose to turn it on it’s head: I remove the www from the hostname using Apache rewrite rules:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^db\.org$ [NC]
RewriteRule ^(.*)$ http://db.org/$1 [R=301,L]

The [NC] flag makes the condition case insensitive. I don’t think I’ve ever seen a HTTP client send the Host: header in anything except lower case, but the relevant standards certainly allow for it.

The R=301 flag tells Apache to make this a permanent redirect. This allows clients to update the links at their end. The L flags tells Apache to stop the rewriting process here and don’t apply any more rewrite rules. This is probably needed if you have additional rewrite rules in your .htaccess file.

The second thing bugging me is the way WordPress does paging. You get a predefined number of posts on the front page, and links to /page/2/, /page/3/ and so on. This holds true for archive, category, tag-cloud and probably others pages as well. The problem with this is that the content on these pages are not stable (it shifts as you post new content) and it duplicates content. I’m still pondering a solution to this…

Igang igjen

Blog

Da gjør vi nok et forsøk på å gjenopplive bloggen. Jeg har tatt med litt innhold fra forrige gang jeg gjorde et forsøk, og utfra datostempelet på disse kan det sees at det er nærmere seks år siden sist jeg skrev noe nevneverdig. Skal forsøke å poste litt hyppigere i tiden fremover :-)

Denne gangen blir det nok også en lett blanding av Norsk og Engelsk. Norsk for ting som stort sett bare er interessant for de som snakker norsk allikevel, og Engelsk for resten.

« previous page