Quicken - Print Securities Within Accounts

I wanted to print a report showing all of my holdings, grouped by account. Quicken 2017 almost cannot do this.

  • Click on INVESTING on the blue bar above the main panel.
  • Choose Show=Value, GroupBy=Accounts, AsOf=(today)
  • Expand each account to show its holdings
  • Right-click on “Show” in the upper-left corner of the main panel
  • Choose “Print this screen”

It can be difficult to see all of the accounts, because the spacing is funny, but they really are all in there.

If you export to text, that also seems to work OK, except it seems to inject blank lines in the middle of some accounts. Also, if your fields aren’t wide enough on the screen, you’ll get “…” in your export. If that happens, go back to the page in Quicken and make the column wider (even if it looks wide enough to you).

Windows Printer Port Configuration Grayed (Disabled)

I needed to change the IP address on a Windows printer. In the search box I entered “Printers” and I selected “Devices and Printers” in Control Panel. Right-click on the printer, choose Printer Properties, and then the Ports tab. Everything is disabled. WTF?


  • Number 1 - you must be logged in as an Administrator. Logout and login if necessary.
  • Go back to the General tab for the printer. You’ll notice that the Configure button has an administrator icon. Click on that. THEN you can update the port.

This might work better:

  • Enter “cmd” in the search box.
  • Right-click on Command Prompt and choose “Run as administrator”.
  • Enter “control” into the command prompt.
  • Navigate to “View devices and printers” under “Hardware and Sound”.
  • Right-click, choose Printer Properties.
  • It was unlocked at this point, for me.

Migrated to Github Pages

I moved my blog from a self-hosted Drupal site to GitHub Pages with Jekyll. I did this for two reasons:

  • I observed an ‘unauthorized update’ to the configuration of my web server.
  • All of my content is static.

I can’t say for certain whether the unauthorized update was an intrusion or my virtual server host updated my configuratino by default. The only change I observed was that someone moved my ssh port. Whoever did it, carefully checked to ensure that the new port was open on the firewall. I can find no evidence of any other changes or activity. My VPS provider states that they did NOT make the change. I suspect that the owner of a different site on the same provider requested a port change on his host and the provider changed mine by mistake.

In the end, there is very little difference – an unauthorized change was made on my server, so now I can’t trust its integrity.

Because my content is entirely static (with the exception of user comments, which I’ve suspended due to spam), Drupal was really overkill. By migrating to GitHub pages, I make someone else responsible for server security – someone who can put a lot more time/effort into it. I retain a local copy of the entire site, so even if GitHub melts down, I can re-publish elsewhere, with no loss of content.

I’m using Jekyll to create my site from Markdown files. Actually publishing a blog post with GitHub + Jekyll is more work (and more technical) than with Drupal, so I’ve wrapped it in a script. At this point, my script assumes that I solely post to my blog from my Macbook. I need to tweak my process and my script so that I can safely add a page from another laptop/PC when I’m away from my Mac.

Prose is a spiffy tool for updating GitHub pages from a web browser. All of the logic is run by the web browser except for authentication. Ohh… Not good. That means that Prose can do anything to GitHub that I can. They say you can host the auth part on your own web server. That might be worth investigating. Links:

  • http://prose.io/#about
  • https://github.com/prose/prose/blob/master/DEPLOYMENT.md
  • https://github.com/prose/browser-extensions - can run from Chrome or Firefox

It looks like it is mostly abandonware. In theory, the only really scary thing is that they could delete my repository. For any other malicious change, I could always revert git.

Ahh… Silly me. You can do this from the GitHub user interface. To edit a file, just browse to the file and press the Edit button. To create a new file, browse to the _posts directory and press the Create New File button.

Prose does have a Preview feature, which GitHub doesn’t.

PKB, Word, Textedit, Markdown, nvalt and File Portability

I left Evernote. As a result, I’m re-thinking my Personal Knowledge Base (PKB) a.k.a. Personal Knowledge Management (PKM).

As givens, I use a Mac, I share data with my Windows-using wife, and I want to be able to read my documents for the next 50 years. I need:

  • A document format which works on Windows and OS X (or has a high-fidelity, low-effort conversion).
  • It works for, “Hey Susan! Take a look at this,” and then email the document or a link.
  • Works for text and images. (See “Take a look at this.”)
  • Not a lot of fuss and complexity. My personal technology environment is so complex that it sometimes dominates my free time to keep things running.
  • Fast data capture.
  • Attractive output with good formatting (rich text).

There are different kinds of documents:

  • Published documents. I don’t modify these. e.g. Bank statements, utility bills, user guides, etc. In the physical world, these are things I would store in a file cabinet or a bookcase. These don’t change.
  • Personal documentation. I modify these slowly, after initial creation. e.g. “How to Set Up My Router”, “What I Gave My Wife for Christmas”, “How to Load Points to Google Maps From a CSV”.
  • Quick capture. When I’m working on a project, I capture lots of snippets and what-I-tried. This frequently results in me having dozens of TextEdit/Notepad files with a few sentences or fragments. These should be short lifetime, but sometimes live for years.

I need Quick Capture and some Personal Documentation to be available quickly-to-immediately when I’m rebuilding my PC/Mac.

Options and Problems

  • Markdown: This is really for just text.
    • Yes, you can write markup to display an image, but the image is stored separate from the Markdown file.
    • You can store the image in a separate file or you can host it on a web site, but you can’t store it in the file.
    • This creates a problem for “Take a look at this” emails to my wife.
    • It also breaks if I forget about the relationship between the image file and the text file and I move one but not the other.
    • (Most of my text files really are just text, but when I have an image, I don’t want the document to lose it.)
    • It works well for the “can read it in 50 years.” It renders well on Mac and Windows (if I don’t lose the image).
    • Dialects of Markdown are a problem. I can’t really just pick “Markdown.” I have to pick a particular dialect. (Tables aren’t in core Gruber Markdown.) Then I have to pick Markdown tools for that variant which work on Windows and Mac.
    • Note: When I say “Markdown” I mean “Markdown without HTML.” I know you can switch to HTML in the middle of a Markdown document, but that loses the readability of raw Markdown and you have to start worrying about the evolution of HTML across 50 years.
  • TextEdit/Wordpad and RTF.
    • Sounds good. Fails in practice. When you include an image in a TextEdit document, it flips from .rtf to .rtfd (at least with El Capitan’s TextEdit).
    • .rtfd is NOT a file. It is a folder which contains files. The images are stored separately from the .rtf. This makes delivery to Windows from Mac bothersome.
    • .rtdf is NOT readable on Windows. Yes, you can view the .rtf file contained in the .rtfd folder, but the images are separate files and are not rendered when you view the .rtf.
    • You can’t convert a .rtfd with images (and retain the images) with TextEdit, textutil, Pandoc, etc. It is rumored that you can do so with Pages.
    • Use TextEdit and save everything as .webarchive? Whoops! Safari and TextEdit know .webarchive. Other browsers speak .mhtml. This flunks the “Look at this” and the read-in-50 tests.
  • TiddlyWiki is OK for some data.
    • It invites excess fiddling.
    • It fails for “Take a look at this” email.
    • It has similar image problems as Markdown. Image files are stored separately from the wiki. You can embed a small amount of images but the wiki will load slowly if you get a lot of graphics. They are stored in base-64.
    • It is ‘iffy’ on the read-in-50. Yes, it is just HTML, but browsers and HTML evolve over time. Try loading a 10 year-old web site you saved in HTML and see whether it renders perfectly. Will JavaScript still be in the browser in 2065? I doubt it.
    • It is great for being available right away, when I’m rebuilding my Mac/PC.
  • nvalt is spiffy for Quick Capture, but it really only works if you write in Markdown or plain text, and you’ve got the separate image and the Markdown variant problems again.
  • Just store everything in .doc or .docx.
    • That’s a pretty damn complex file format. I’m not sure it passes the read-it-in-50 criterion.
    • I don’t have Word on my Mac.
      • I could use LibreOffice. LibreOffice launches so slowly that I’ll start stashing things elsewhere when I’m in a hurry working on a project. It isn’t there early in the OS rebuild process.
      • I could install Office for Mac. I really hate the whole activation thing. “Hello Microsoft. May I please run the software I purchased 10 years ago?” Sure. $150 too.
      • I could run Office in a Windows VM. (I do, actually.) If I leave VMware Fusion running when I hibernate my Mac, it creates an intermittent wake-from-sleep failure. Microsoft product activation is a problem here too. $150 (plus Windows) too.
  • Google Docs? I left Evernote because I don’t trust my confidential data to cloud providers. Not all of my data is confidential, but keeping track of which is which and which is where is friction.
  • ODF/ODT instead of .doc? Well, it isn’t proprietary, but I still would have the LibreOffice issues or the issues of cost and product activation with Word.
  • Maybe I’ll create all my documents using LaTex. (Snark.)

Sheesh! I begin to understand why RFCs are issued in plain plain text.


  • This is a good document on document lifetime. Good perspective. They seem to prefer the MultiMarkdown dialect.
  • I could use Archivematica to address long-term document readability. Archivematica’s media-type preservation plans convert .doc, .rtf, and other word processing files to Open Document Format (ODF) for preservation and to Adobe’s PDF for viewing. It fails the simplicity test. It would complicate my technology platform.

bash - Remove File Type

I never can remember this:

echo ${filename%.*}

will remove the trailing “.txt”. Mnemonic: % sorta looks like dividing two circles. “%.*” says to divide at the period, matching any file type.

I often use a for loop which looks something like:

for f in foo*.txt ; do
    echo ${f%.txt}

Keyword fodder: bash, shell script, remove file type, remove file extension, basename, base name, Linux, Unix

Kevin's Table of OpenVPN Keys, Certificates, and Authorities

Kevin’s Big List o’ Files

Sometimes I run OpenVPN on a Linux server. Sometimes I run OpenVPN on a consumer-grade router with a built-in OpenVPN. Just to be “helpful”, they don’t use identical terminology. Here’s where I keep it straight.

You’re going to need a bunch of files with certificates.  You’ll give some of these to the server, some to the clients, and some you’ll keep secretly filed away. (See also this .)

File Name

Merlin’s Name

Needed By




(settings from checkboxes, textboxes, etc.)


configuration options



Certificate Authority

server + clients

CA Root Certificate




key signing machine only

Root CA private key



Diffie Hellman parameters


Diffie Hellman parameters



Server Certificate


Server Certificate



Server Key


Server Key





Client Certificate





Client Key


ta.key (static.key)

Static Key

server + clients

Extra, optional security for connecting



Certificate Revocation List


Blacklisting of certificates



Extra Chain Certificates


Merlin has this field. I don't know what it's for.


.csr files

(not referenced)

key generation machine

Intermediate files for building certificates


Details of files:

  • ca.crt

    • All of your keys/certificates will be signed by a root certificate authority (CA). This is the certificate of your CA. You can act as your own CA or you can use a commercial CA. This document assumes you act as your own CA. Any (non-revoked) client certificate signed by this CA will be able to login to your VPN, so you may want a unique CA certificate for your VPN.

  • ca.key

    • This is the private key of your CA. You need it on you key generation machine. You do not need it on your VPN server.

  • dh{n}.pem, dh.pem

    • The Diffie Hellman algorithm generates a unique *session* key via a well-known algorithm. This is a seed for that algorithm. It allows you to "create an encryption key with someone, and then start encrypting your traffic with that key. And even if the traffic is recorded and later analyzed, there's absolutely no way to figure out what the key was.” Contrary to my expectation, you don’t have to keep this secret because parts of the DH exchange are random values. Sometimes this file is named dh2048.pem (or dh4096.pem); sometimes it is named dh.pem.

  • server.crt

    • This identifies your VPN server and contains its public key. Merlin names it server.crt. I generate two server certificates: server-raspi.crt and server-router.crt

  • server.key

    • This is your VPN server’s private key. Merlin names it server.key. I generate two server certificates: server-raspi.key and server-router.key

  • user-{n}.crt, user-pass-{n}

    • This identifies your client and contains its public key. There is one per client. Some of these are named user-pass-{n}. Those users have passworded keys.

  • user-{n}.key, user-pass-{n}

    • This is your client’s private key. There is one per client. Some of these are named user-pass-{n}. Those users have passworded keys.

  • ta.key (static.key)

    • Used for "Extra HMAC authorization” (Merlin’s name) or the “tls-auth” configuration line in OpenVPN.  This is an optional, *extra* key, used to authenticate the TLS handshake.  When your client makes its initial connection to the server, this information gets passed.  If the client doesn’t pass it, the server doesn’t respond, protecting against some attacks. OpenVPN has 2 authentication modes.  “Static Key” and “TLS”. Merlin overloads this field and uses it for BOTH methods’ static key. Merlin calls it "static.key". In my Linux config, I name it "ta.key". With Merlin, you must set “TLS control channel security” = 0, or this file won't be created.

  • crl.pem

    • Used to revoke or blacklist certificates. You revoke a certificate when someone loses the laptop/phone with that certificate. Or maybe you revoke your ex-spouse's certificate when the divorce is final. ;-)

  • .csr files

    • In order to create a certificate, you collect some data and get it signed by your Certificate Authority. The .csr files are input to the CA signing. The signed .crt files are the output. Once you have the .crt, you don't need the .csr.

I hope that helps to keep everything straight. It can be confusing!

Certificates, Keys, and Authorities


VPNs use certificates and keys. We’re going to spend some time building certificates and keys, so we should get clear on what they are.

  • A certificate is used to prove who you are. (More accurately, it proves that a computer is who it says it is.) A driver’s license is an example of a non-computer certificate.
  • A key is used to lock/unlock something. (More accurately, it encrypts or decrypts something.) The key to your front door is an example of a non-computer key.
  • A certificate authority is used to mark certificates and keys as being ‘official.’

Certificates and encryption are what make OpenVPN secure. Managing client certificates is a big part of managing any VPN server. I’m going to generate a server certificate and I’m going to generate many client certificates. It will be more than I think I’ll need, but I’ll go ahead and generate them all now, before I forget how. I’ll use a tool called easy-rsa.

Return to Surf Safe at Starbucks

Build the Keys and Certificates You Need for Your OpenVPN Server and Clients

  • Summary: Install easy-rsa, configure it, generate CA+key+certs

We’re going to use a tool called easy-rsa to build your keys and certificates. You can install easy-rsa on your Pi and run it there, but you only need easy-rsa when you’re building keys/certificates – not when you are using them (and using your VPN). I prefer to build them on my Mac. If you are a Windows user, you can build your keys on a Windows PC, but you’ll find it easier to build them on your Pi. Generating keys is slow on a Pi, but it is faster to run easy-rsa on a slow Pi than it is to figure out how to make it work on a fast Windows PC.

I’m going to refer to your ‘key generation machine’ and your ‘VPN server’. Your key generation machine is the machine you’re using to run easy-rsa, whether you decided to use your Pi, a Mac, a Windows PC, etc.

Install Software

If your key generation machine is your Pi:

sudo apt-get install openvpn
mkdir ~/Packages
cp -r /usr/share/easy-rsa ~/Packages

If your key generation machine is a Mac, browse to the OpenVPN github site and download EasyRSA-2.2.2.tgz. (There are some significant changes with v3, so you’ll have some challenges if you use my instructions with 3.x. As near as I can tell, there’s nothing obsolete about the keys/certificates which 2.2.2 generates. 3.x just provides a different model for generating certs – and breaks all the old commands.) Then, in the directory where you downloaded it:

    tar -zxvf EasyRSA-2.2.2.tgz
    mkdir ~/Packages
    rm EasyRSA-2.2.2.tgz
    mv EasyRSA-2.2.2 easy-rsa
    mv easy-rsa ~/Packages/

If you’re running it on Windows, install easy-rsa 2.2.2 from https://github.com/OpenVPN/easy-rsa/releases. I’m not going to provide instructions for Windows. If you’re determined enough to make it work on Windows, you don’t need my help!

Note: Throughout these instructions, I’ll refer to your home directory as /Users/kevin. This is probably NOT your home directory. You should substitute YOUR home directory. On a Pi, your home directory is probably /home/pi. I’m running easy-rsa from /Users/kevin/Packages/easy-rsa. You should substitute the path where you installed easy-rsa.

When we’re done with certificates:

  • ~/Packages/easy-rsa/keys_xxxxx on the key generation machine will contain your ‘master’ copy of keys and certificates. Preserve this data for future redeploys in case your VPN server’s disk fails or one of your client’s disk gets wiped! You want to keep this directory secure, because anyone with access to it can use your VPN. You should probably NOT leave this data on your OpenVPN server because if someone got ahold of the CA key, they could generate all the client keys they wanted, and you might not notice.
    • It it common to simply use ~/easy-rsa/keys. For bonus points, I’m building keys for TWO VPNs at once. I plan to run one VPN on a Raspberry Pi and the other on a consumer router that includes OpenVPN. So I need two ‘keys’ directories. Also, I have many subfolders of my home folder, and I group code-plus-data packages into ~/Packages.
  • /etc/openvpn/server1 on your VPN server will contain your server’s private key, in addition to some less confidential keys and certificates. You want to keep this directory secure, because anyone with access to it can masquerade as your VPN server.

Configuring easy-rsa

Continuing, execute the following on your key generation machine:

  • If you have a file named ~/.profile, add the following to that file. If you don’t have a .profile and you do have a .bash_profile, add the line to it.

      alias easy-rsa="cd /Users/kevin/Packages/easy-rsa; source vars"
  • Then source .profile or .bash_profile, as appropriate. e.g.

      source .bash_profile
  • Then run it:

  • Edit ./vars and change these variables. Use values that match your situation. These apply to me but may not to you!

      export KEY_DIR=keys_raspivpn            # TODO: Later, use keys_routervpn
      export EASY_RSA="/Users/kevin/Packages/easy-rsa"
      export KEY_SIZE=2048
      export CA_EXPIRE=10000
      export KEY_EXPIRE=10000  
      export KEY_COUNTRY="US"
      export KEY_PROVINCE="GA"
      export KEY_CITY="Atlanta"
      export KEY_ORG="KleinfelterFamily"
      export KEY_EMAIL="kevin@example.com"    #TODO: Changeme
      export KEY_OU="RaspiVPN"                #TODO: Later, use RouterVPN
  • Estimates are that a 2048 bit key is good to the year 2030. I’d prefer not to come back and re-do this in 15 years, so I’d like a 4096-bit key, but there are stories that performance with a key that large can be poor on some devices. I plan to use this with cell phones with limited CPU and battery, so I’m going with 2048.
  • I’m also setting expirations to 10,000 days which is 27 years. I’ve never seen the merit of date-limited CRLs. I would have gone higher, but when I used 12,000, it said that the CRL was already expired, whenever I used it or when I revoked a cert.
  • Edit openssl*.cnf and set:

  • If you don’t do this, your CRL will expire in a month and when your CRL expires, the server will refuse ALL logins.
  • Then run:

      source vars
      mkdir "$KEY_DIR"
  • Mac only: If you are on Linux, openvpn should already be on your path. If you are on Mac, you may have to add openvpn to your path. OpenVPN is bundled with Tunnelblick. If you install a different version of Tunnelblick than the one I used, you may have to tinker with PATH. After you run the “ls”, adjust the PATH statement below to use your latest openvpn-x-openssl-y.
    • ls -l /Applications/Tunnelblick.app/Contents/Resources/openvpn/
    • Edit your ~/.bash_profile and add something like:

        export PATH="$PATH:$TBSSL"
    • Be sure to “source ~/.bash_profile”.

Build CA and Server Key

  • Enough setup! It is time to build your OpenVPN data. Begin by emptying your easy-rsa keys folder. You don’t really have to do this the first time, but this step is here in case you come back to re-do your keys. (I did.)

  • Build your Certificate Authority. Your keys are all signed by this CA.
    • This isn’t a globally trusted CA, but that’s OK because you’re the only person who has to trust it.
    • If you’re building two VPNs, take all the defaults EXCEPT ONE when it asks. (If you’re building just one, you can take ALL the defaults):
      • For “Common Name (eg, your name or your server’s hostname) [KleinfelterFamily CA]”, tell it
        • KleinfelterFamily.RaspiVPN CA (when you’re building keys for your Pi-based VPN.
        • KleinfelterFamily.RouterVPN CA (when you’re building keys for your router-based VPN.
    • Run this:

      • Keep responding to build-ca prompts with enter (except on Common Name) until you’re back at the shell prompt.
      • Note: Since I’m building two VPNs, I will end up creating two CA. I need two CA because I need one VPN server to trust one CA and the other VPN server to trust the other CA. If I used just one CA, all of my users could use both of my VPNs.
  • Build your server key and name it with the given name. Take all the defaults when it asks. When it asks whether to sign it, say yes. Ditto for committing your changes. I’m naming my cert “server-raspi”. You might want to name yours something more suitable for you.

      ./build-key-server server-raspi      # TODO: Later, use server-router
  • We’ll use the TLS authentication key to harden your server against DDOS attacks which make excessive connections to your server. Connections to the OpenVPN port don’t happen without a valid ta.key.

      openvpn --genkey --secret "$KEY_DIR/ta.key"
  • Build the Diffie-Hellman data. DH data plus some random data is used to generate session keys. This took 20 minutes on my Pi. You might consider running it with nohup. One time, it ran for over 4 hours without completing. I killed it and restarted it. Since ‘random’ is involved, that may explain the difference, but I’m not certain.


Client Keys

We’re going to build 40 keys, permitting up to 40 clients. You can come back and build more keys later, but by then I will have forgotten how. Build a nice big supply of them now, and store them somewhere safe. Distribute them as needed. Make a little readme.txt in your keys folder to track where you use each one.

Note that the script below will create some unpassworded keys. With one of these keys, you can login to the VPN without a password. Passworded keys are built with ./build-key-pass instead of ./build-key. (When it asks for PEM pass phrase, assign it a password. This is the password you will use to unlock this key.) If one of your VPN ‘clients’ is an unattended server, that doesn’t work smoothly with a passworded key. My keys will go on my family’s computers and phones. These are all passworded devices and if someone loses one, I’ll revoke the key before the finder can crack the password..

If you use ./build-key-pass, you’ll want to enter the desired password for PEM passphrase. ‘‘Do NOT enter a value for “challenge” password.’’

If you built your keys on your Mac, execute the following commands on your Mac. If you built your keys on your Pi, execute these commands on your Pi. (It is probably wise to put these in a shell script and run it.)

You must respond ‘y’ to the prompt to sign the certificate and the prompt to commit. Everything else can be left at the default.

Note: easy-rsa is an interface designed for low volume. We’re going to push a lot of requests through it and if we get one response wrong, we create a mess. Open up a text note and put exactly 10 newlines in it. Copy them into your clipboard. (Check via paste into another document, to be sure you have exactly 10.) After pressing enter to respond to the prompt about entering a suffix, paste your 10 newlines. This should take you right up to the prompt to commit.

If you make a mistake and you see, “CERTIFICATE WILL NOT BE CERTIFIED”, press control-C to interrupt, delete that key, edit your script to start with that key, and continue. Nothing is permanent in the ‘database’ until you commit the change. If you commit a bad change, you have to start over at “./build-ca”. (I think.)

  • After responding to the suffix prompt, paste your 10 newlines.

For myself, I created the following NAMED un-passworded: kevin-mac, kevin-windows, kevin-cell

And the following NAMED passworded: wife-pc, wife-cell, kid1-pc, kid1-cell, kid2-pc, kid2-cell

function getsuffix {
    echo  "Building $1.  You can attach a suffix to the key name like 'Jane'" 1>&2
    echo -n "Enter your suffix or press enter for no suffix:" 1>&2
    read suffix
    if [ "." = ".$suffix" ] ; then
        echo "$1"
        echo "$suffix"
echo "BEGIN unpassworded keys"
for i in {01..15} 01-bogus 02-bogus initialize-crl ; do
    ./build-key "user-$(getsuffix $i)"
echo "END unpassworded keys"
echo "BEGIN passworded keys"
for i in {15..30} ; do
    ./build-key-pass "user-pass-$(getsuffix $i)"

In this example, we created unpassworded keys and passworded keys, plus we’re creating bogus keys so we can practice/validate our CRL (Certificate Revocation List). We will use “initialize-crl” to seed our CRL later. Save your passwords in your keys folder in a readme.txt and “chmod go-rw readme.txt”. You’ll have to provide these passwords to your users and they won’t be able to change them, so you might want to come up with unique passwords for each user.

Reminder: Your client keys and certificates do NOT need to be stored on your VPN server.

Initialize the CRL

./revoke-full initialize-crl

Old Cell Phones

Note: For some older iOS and Android devices, there’s a rumor that you’ll need to convert the key to a triple-DES (3DES) key. You do that with a line like the following, but I’ve not got devices old enough to require DES, so I didn’t use it. If you used build-key-pass, you’ll provide the desired password at the “Enter PEM pass phrase” prompt.

openssl rsa -in Client1.key -des3 -out Client1.3des.key # Do not run unless you know you need it.

If you’re me, and you’re building TWO servers, go back and do everything on this page again, for the second server, using the second server’s name at the TODO items, beginning with “Configuring easy-rsa”.

After you’ve created two sets of keys, edit the “vars” file and replace this:

export KEY_DIR=keys_routervpn

with this

echo -n "Do you want KEY_DIR to be $EASY_RSA/keys_routervpn? (y/n)[y]:"
read response
if [ ".$response" != ".n" ] ; then
    echo -n "Do you want KEY_DIR to be $EASY_RSA/keys_raspivpn? (y/n)[y]:"
    read response
    if [ ".$response" != ".n" ] ; then
        echo -n "What sub-directory of $EASY_RSA will you use for KEY_DIR? [keys]:"
        read response
        if [ "." = "$response" ] ; then response=keys ; fi
echo "Using KEY_DIR=$EASY_RSA/$choice"

What Have I Created?

See OpenVPN Keys, Certificates, and Authorities for a reference.

Keep all of the .key files secure and confidential. Use “chmod go-rwx” on your keys folder.

Back to Surf Safe at Starbucks

Keys, Certificates, Certificate Authorities, are Like Your U.S. Passport

  • Summary: Server can accept any CA-approved cert without a list of authorized users

When I found out that my OpenVPN server didn’t need a list of valid user IDs, I was nonplussed. How can you have a server without a list of authorized users? Let me draw an analogy…

When you travel abroad, you take your passport. When you return to the country, you present your passport to Customs. They check your passport to see if it is valid. Unless you are on a blacklist, they let you in (if you haven’t stuffed a pound of cocaine into your underwear!)

Customs does not have a list of citizens and they don’t check to see if you are on the list of people to admit. They only check to see if your credentials are good and if you are on a blacklist. They can do this because we all agree that the State Department has the authority to issue passports.

When your VPN and your client certificates are created, they are signed by a Certificate Authority (CA). Both your client and the server have a copy of the CA’s certificate and its public key.

When you login to the VPN server, your VPN client sends your certificate. The server looks at your certificate and sees that it was issued by the CA. It uses the CA’s public key to validate your certificate as having been issued by that CA. Part of your certificate was encrypted by the CA’s private key, so only the CA’s public key can decrypt it. That’s how the server knows that your certificate really was issued by the CA.

Your certificate is like your passport. The server looks at the certificate, just like Customs looks at your passport. If your certificate is issued by a CA your server trusts, it lets you in – just like Customs lets you in if your passport is issued by the State Department. It also checks to see if you’re on a blacklist (a Certificate Revocation List, or CRL). If you’re not on the CRL, you’re logged in.

In addition, your client sends its public key to the server. Your client uses your private key to encrypt traffic, so the server needs your public key in order to decrypt it.

Note: You can choose to set up your server to require BOTH a certificate and to also have a list of authorized ID/password pairs. It’s your choice.

Return to Safe Surfing at Starbucks