I have a complete change of heart on this. Now I recommend this:
Which is actually explaining the use of this:
I have a complete change of heart on this. Now I recommend this:
Which is actually explaining the use of this:
(I never went back and edited this. That means it's probably a little rough and may be confusing.)
Secure email requires encryption. Encryption requires two keys. One is called a public key, a sender can use this to encrypt a message. The other is called a private key. It can be used to decrypt a message that was encrypted with the corresponding public key.
When you send secure email, there are two functions. One is called 'signing'. In a signed message, the mail program uses the recipient's public key to create something called a digest. The recipient can open the digest (with their private key) and verify that the email is exactly the one that was sent. The other security function is called encrypting. In this case, the sender uses a public key to put an encrypted form of the message into the email and send that instead. The recipient uses his or her private key to decrypt the message into a readable form that security people call plaintext.
When you send an encrypted or signed email to a list of people, a different key is used for each person. A different encrypted package is sent to each. Each uses his or her personal private key to open the message. You cannot send an encrypted message to a list of people that includes someone for whom you do not have a public key.
Managing the keys is done with something called certificates. The certificate contains both the public and the private key and information that allows the mail program (in cases where its important enough to pay the certificate company) to verify that you are you and that this is your key.
To start, get a free certificate at:
After executing the signup, it will email your the certificate.
- Double click on the attachment in the email from Comodo tol open Keychain Access.
It will automatically install the certificate.
To verify that it all works, quit Mail.app and restart it. Create a new email and you will see new icons on the left of the subject line.
That blue check means your emails are now signed. If some hacker messes with the message before it gets to me, I will get a notification that the message is not the one you sent. The grayed out lock symbol says that you are not yet able to send an encrypted email, yet.
To be able to send encrypted email, your email program has to have the other person’s public key. Mail.app collects these when it gets a signed email. To send an encrypted email, ask the person (I have one so I'm a good option) to send you a signed one and reply (or Mail.app may already have it). The lock should turn blue in a new message to that person.
But, when you receive an encrypted message (eg, when I reply to your first encrypted message), you will see that you cannot read it on your iPhone. The problem is that your iPhone needs to have your certificate as well.
NOTE: YOU DO NOT NEED TO DO THIS. THE EXPORT FROM KEYCHAIN CAN BE SENT. I DON'T REMEMBER EXACTLY WHAT I DID, SO I AM LEAVING THIS PART IN.
To update your iPhone with a certificate, you need a new program called the iPhone Configuration Utility.
Download it from
Install it like any other program. It gets installed into "Applications/Utility/IPhone Configuration Utility".
Open Keychain Access
- Find the certificate that was installed before in the ‘login’ keychain. It is named as your email address. If you have old ones, it will probably be the one with the latest expiration date.
- Select it and choose Export Items from the File menu.
You will see a file dialog. In addition to files, it will show a popup men under the file list.
- Choose “Personal Information Exchange (p12)”
- Save the file someplace easy to find again (Desktop is good. You can throw it away after this is done.)
Open iPhone Configuration Utility.
- Select “Configuration Profiles” from the palette in the left column
- Click the New icon on the top left.
This will show a new set of controls in the lower left window.
Select the General item.
-` Make up an informative name .
- Then make up a unique Identifier. For this purpose, I suggest something like com.domain.emailCert.yourEmailName.
Leave Description and Security as they are (blank, or whatever you want to type, and Always).
Next, scroll down from General and find Credentials.
- Click on the Configure button that shows and you will see a file dialog. Choose the p12 file you made before and Open.
The final act in Configuration Utility is to click Share, next to the New icon.
- Select None from the Security popup and Share…. This will take you to Mail.app.
There you will see a new mail message with a file attached. Email this to yourself.
The last step is to open the email on your iPhone and tap the certificate.
It will open.
- Click the button, top left, that says Install. It will ask for your phone’s password.
- Enter your password and click Done. It will tell you that the profile is not signed.
- Click Install. It will ask you to do it again to confirm.
- Click Install again (this time red and at the bottom).
It will return you to your email message and you are done.
(You can look at it or delete it by going to Settings->General->Profile. It’s way down at the bottom).
Now you can find the email that you couldn’t read before and you will be able to read it.
I just renewed the certificate for a client web store. This is a task that drives me crazy because I do it so infrequently that I can never remember the details. It's made worse by the fact that I use InstantSSL, a company whose documentation and practices are incredibly confusing. Also, cheap.
Here's what happened.
I followed the usual instructions for generating a Certificate Signing Request. This generated two files, a .csr and a .key (for later).
I used a command line like this:
openssl req -new -newkey rsa:2048 -nodes -keyout myDomainName.key -out myDomainName.csr
It is entirely unclear to me if the name of the files makes any difference. Also, in the dialog that openssl conducts to construct the CSR, it asks for "your name". It means 'your domain name'. May be obvious but I thought that maybe it was picking up the domain name from the command line.
The purchase process for InstantSSL is pretty easy. They are really good at taking money.
Since I screwed up the domain name thing, I had to interact with tech support and give them a new CSR. This was annoying since it just said I needed to do it, not how. Eventually I had looked around long enough that I felt like I had to call. Turns out you have to construct a support account and treat send it through the support website along with your order number.
The next step was validation. It does two things. It looks up the company phone number (in this case using Dunn & Bradstreet). I had to work with the client to be there to answer the phone and gather the 'validation code'. Entering this into the phone call tool triggers another email (this came to me, as the email address on the purchase) with another, longer validation code. This had to be put into the order control panel.
While there, I saw that it still wanted to send email to admin@, an address that does not exist, for additional validation. Turns out that, in the order control panel, you can change this to one of several other options. I don't know where they come from but, one of them was me. That sent another validation code to put into the order control panel.
And then I got an email with a .zip full of certification. Expanding this got me two files, a .crt and a .ca-bundle. I also needed the .key file made along with the CSR.
These were put into folders specified in the Apache config file. In my case, this was a virtual host file for that site.
There are three files and they need three entries for Apache configuration:
On my system, these are root files with permission 644. I do not know if this is ideal. There might be some more secure arrangement. (That's what comments are for.)
After a server restart, the browser security violation went away and things look pretty good.
Now you know.
src: local('demoFont'), url(http://static.someDomain.com/demoFont.ttf) format('ttf');
src: local('demoFont'), url(http://static.someDomain.com/demoFont.woff) format('woff');
Header set Access-Control-Allow-Origin "*"
ln -s ../mods-available/headers.load headers.load
service apache2 restart
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/tqwhite/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
bad ownership or modes for directory
chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
sudo chown root:root /root
DigitalOcean solved the problem and made life good again. We achieved understanding of the specifics of my need and that it is a valid one. Their preferred solution will require changes to their system that might be made in the future. In the meantime, they have agreed that I can have more than one account. That means that I can use DigitalOcean in the way that suits my needs.
Almost more importantly, it means that I can love DigitalOcean again. I told the guy that I feel silly because I actually had hurt feelings and was sad at the prospect of not feeling the DigitalOcean love. I guess I feel even sillier at my elation at having them not only satisfy my need but actually exert the effort to go through conflict to a happy resolution.
The title of this post has been changed from "Rough Experience" to "Awesome Experience with DigitalOcean".
I heard from a different Digital Ocean guy this morning. He was incredibly nice, clearly had read and paid attention to what was said last night and made suggestions for ways to solve my problem. I don't know what the resolution will be but, I'm leaving this post up both so he can read it to understand what I'm trying to do and so that the rest of the world can know that these guys are not only trying to provide an awesome service but are willing to reverse course when they see that they are injuring a customer relationship. I think that might even be more important than getting it right the first time.
Digital Ocean kicked me out last night when I tried to start a new client account using my own credit card. They told me that they are "not comfortable" with me using my credit card for more than two accounts (I have another client I put there already). Huh? Not comfortable using my 100% valid credit card to pay for multiple accounts?
It turns out that there are lots of people who want a minimal website and have no way of getting it. When a friend or family member knows one of those people, I sometimes end up making a small website for them. For years, I've just hosted the site on one of my servers. They never have any real traffic so it doesn't cost me anything.
But, I hate it. I have some sites that have been in my life for years and, if I want to change servers, I know I have to move those sites, too. What I really want is to be able to quickly fire up the site and then hand it off to the person. Most of them are happy to pay a few bucks to keep it alive. (I don't take the money because I don't want to do the paperwork.) I'm happy to help again if they need it, but I really would like to have it be their responsibility.
I've thought about just pushing them to a shared host, but, I've not seen one that didn't require a whole other learning curve. More importantly, I manage my software with git and no command line is a problem. And, I put parameters in my virtual host file to drive my software. Putting these sites a virtual host that would support how I want to work is too expensive for them.
Enter Digital Ocean.
These guys offer a very straightforward system to generate a virtual private server on the web. Their smallest instance comes out to about $5.00 a month. I can have a website based on my software up and running there in about twenty minutes.
Aha! A solution to my problem. I can quickly generate the new, tiny site. Because it's cheap, I can afford to host it as a gift for awhile or I can pass the account on to the person or I can invoice them and manage it myself. In all cases, if the client wants to use some other web guy, I can just hand over the password. Or, if I don't want to mess with it any more, I can just hand over the password. Or, as is the case with one more substantial client, I can fire them – and just send them the password.
The point is that I can, in an email, give the site to the client and be done with it. I do not have to do a whole project to change their DNS, initialize a server, blah blah blah. Send the password. Be done.
This notion came to me this summer. Having my own Digital Ocean account, I fired up a new account for a new client and started to work. This one is a little larger than the main use case but, the principal of being able to turn the whole thing over to them when appropriate still applies. Then a friend asked me if I could help out one of her friends.
Sure!, says I. I have this awesome new service available. I'll fire it up tonight. He can send me sixty bucks for this first year of service and Bingo!, we will have his little site working before sunup.
So, I hit Digital Ocean and create the account. I enter my credit card and, Bam!, the site tells me their fraud detector has found me wanting. The messages are all nice and unthreatening. Almost immediately, I get an email asking why I made more than one account with the same credit card. I think, "oh! I can understand that", and explain my situation.
Imagine my surprise when that's not enough. (No! You can't buy three things from me using the same credit card.)
I engage with some customer service guy. He tells me that they have "standard procedures". He asks how we should resolve this. Thinking, "Really, your standard procedures say, 'don't let TQ give you an extra five bucks a month?"
Instead, I tell him that it makes sense to have his software detect my anomalous behavior but, having investigated me and found me to be a real person, it seems like the 'standard procedure' should be to green light my account and let me get to work.
"We are not comfortable"
But, he ignores what I wrote (It's weird. when I reviewed the emails this morning, it's like I was talking to an automated system. He never actually responded anything I said.) and, after asking me to repeat my earlier explanation (was he really paying that little attention?), tells me that they are "not comfortable moving forward" with more than two accounts.
Where I come from, "not comfortable" is the same as "we don't feel like it." He offers no real reason. In my ire, I assume that he doesn't really care how I feel about, at least not enough to tell me the real reason – or, more likely, there isn't one. It really is that they value their procedures over my business.
I told him that I was bummed out about his discomfort and that he could delete the account I made but won't be able to use. He told me that he wasn't going to do the deleting. I have to do it. He explained the procedure I should go through.
I believe the real meaning of that was, "I just told you we are not going to work with you because we don't feel like it. What makes you think we are going to do anything for you. Now, you go clean up our server."
I have come to really value companies that want to have a good, supportive relationship with me. I send email to the Bare Bones software (make of bbedit, my code editor) and get a response from the principal guy. My main server host, Server Grove, tries to help me out when I contact them. Their main guy sometimes gets involved. There have been occasions when he actually did stuff that I know he didn't have to do to help me. I feel good about those companies and tell everyone how much I like them.
Digital Ocean has such a nice website and a good service. I thought I had found another company to solve a problem that has been bugging me forever.
In case you were wondering, I have decided that I am opposed to the current proposal to tax internet sales transactions.
I am, generally, sympathetic to the problem of lost revenue and competitive advantage given to online vendors over bricks and mortar. It's a distortion in the market that could encourage a death spiral where anyone in my neighborhood has to be driven out of business because they have a structural price disadvantage - at least if you ignore shipping.
However, I note that sales tax is considered to be the most regressive way to get revenue. It makes me a little suspicious when we have Republican support for a tax increase. If they support it, I figure it's going to turn out badly for me.
But, more important is the part where it makes it so that we are all at risk of being involved with any tax authority in the country whenever we do business on the internet. This seems to me a little like searches at airports. Sure, there's a 'reason' but it is actually a checkpoint where you have to ask the government for permission to travel.
I suspect that adding sales tax to the internet will be another way that we put an instrument on the net that will put more of us in a position to be troubled by the government. Unlike a garage sale, the internet keeps a record. That means that the piece of Craig's list crap you sell to someone in Alabama, well, that means the Alabama Dept of Revenue owns a piece of your ass.
If the sums were huge, I might still be swayed in support but, this tax will produce something like $23 billion. That's 5% of the defense budget, not including wars.
That tells me that there is something else going on. I don't know what it is but, when the corporatists in Washington get together to add a tax that will affect everyone that ever wants to sell something using the internet, I am very suspicious.
Here's are the two bugs: The declaration of private was made one of the child classes but not in the parent.
Here's the behavior: A parent class makes an assignment to a property
when accessed by class A, it works fine, by class B, the assignment is not made.
It turns out that, I had tried doing this work in class B before I decided that the better strategy was to put it into the base class (for both A & B). When I abandoned that effort, I inadvertently left the property declaration (private $routeName) in class B. It never was in class A.
The base class already had a property of that name. What I did not know is that, despite the long list of declarations that prove my intention to declare all properties, $routeName was not, in fact, declared.
That means that, from the base class perspective, the property could not be assigned. Incredibly, though I have PHP set to complain about everything, it did not complain about this attempt to assign to a private property. It failed silently and, since I was focused on the base class, inscrutably.
Once I noticed that the property wasn't declared in the base, I did so and it worked.
I experimented and found that, if I removed the declaration from the child class B, it worked. If I changed the declaration to protected, it worked just fine, too. (Much to the consternation of a co-worker who considers it blasphemy to have a declaration in a child class be available to a parent.)
Of course, the correct solution was to remove the declaration from the child, add it to the parent, and get back to work.