4

Background - I need to set up secure remote access for a small home office. I'm a bit of a noob and haven't needed to handle certificates before. I understand most of the setup but I want to understand the practical implications of certificate management as I have to manage the CA side too.

LAN summary

Simple open source router with LAN devices (mainly PCs and printer) all linked by an unmanaged switch and having a public bank of 16 IPs. There are no VLANs, no domain/radius login, no other LAN services, and no local DNS (I'm comfortable just using pure DHCP and IPs). The router natively supports incoming IPSEC/L2TP/OpenVPN. I'm tentatively leaning toward OpenVPN if there aren't good reasons for going with another (but I admit that I don't really know the practical differences).

Question:

The concern is that poor config can expose the client to the outside world. As the CA for the LAN, I have to think about the private/signing certs, and everything else, not just public certs. So I want to ensure that the security-related files generated (private certs, master keys, signing keys, whatever) are properly handled and kept+managed appropriately securely. But most resources of a level I can understand omit or are vague about security practices post-setup.

So... as a manager of the certification process (seen from the router/CA perspective) what exact certificates/keys/self-CAs must I set up, and what certificate management files must I protect and how should I do it? (file encryption on my laptop, separate USB stick, dedicated non-networked laptop, ...?) How often do I need to access these, once it's set up (security v. convenience)? Would "most" implementations store these encrypted, or do I need to worry about how the router itself holds them?

Thanks for any help!

Update 1 - Updating to clarify the roles a bit, as they aren't the same as might be expected. Usually one imagines a developer or site owner certifying to third parties via an independent CA, or an independent CA and the site owner creating certificates for various other parties. Here it's much simpler. The only purpose of creating any CA/certificates/keys is to allow one person (the LAN owner and nobody else) to connect to the LAN securely using one mechanism when away (router-native VPN) and to be sure others can't do so (within the limits of usual security disclaimers). Once it's all set up and working nicely, additional certs/keys may only rarely be needed.

The real-world scenario is that the owner has to move out shortly as the place won't be habitable due to major building works for 18 months, but the LAN will stay. My question isn't really how to generate keys and certs which has many HOWTOs, it's about the ITSec knowledge most relevant to his scenario; I'd like to bootstrap myself a bit better on the procedural knowhow, so when I follow the recipes, I have some degree of comfort that I'm not just following them, but keeping what's created fairly well secured, and not likely to be leaving the LAN all-but-open by ignorance while it's 'live' afterwards. I need some pointers what I need to do to be as sure as I can, that I'm giving him a reasonably secure setup and managing it reasonably sanely.

I probably worded that a bit dramatically :) but with luck it distinguishes and clarifies the question asked.

2 Answers 2

2

Despite Alexey Vesnin's answer, feel free to keep the certificates you issued for various reasons. They are considered public knowledge and no harm is done whatsover keeping them as long as you like.

Having said that:

Being a CA comes with some responibilities:

  • Make sure you keep the private key safe and secure. (An encrypted USB stick with the CA data on it will be fine, as long as the machine you decrypt it on is not compromised. A smart card would be a better (albeit more expensive) solution.)
  • Offer the parties relying on your certificates a way to check for revoked certificates (for example, if a key pair somehow gets compromised
  • Make sure compromised keys/certificates are reported to you (do not punish the people for being not careful enough)
  • Make sure to revoke certificates as soon as you see the need
  • Make sure you inspect every CSR you get from clients thoroughly before signing it

Depending on your actual use case (does every client need a certificate? How much fluctuation is there? How good are the clients in keeping their private key private?) you might only need to work with your CA setup when the initially granted certificates are about to expire.

Or every other day, that completely depends.

Additional considerations for the changed question

You might only need the LAN side to trust the self-signed certificate of the only connecting party (and vise vesa). As long as the two machines are trusted, you may just add the certificates itself to the trust store and leave out an actual CA signing both certificates.

9
  • An encrypted USB stick isn't that different from just keeping them on a computer, as in both cases the private keys can be read and copied by malicious software running on any computer you connect the USB stick and decrypt it. What you need is a smartcard, which will allow you to do operations with the key without revealing the key itself. CAs use HSMs which are like big smartcards but for a home/small office a basic PKI card will be fine. Mar 25, 2016 at 9:18
  • @AndréBorie you are right; I edited my answer to reflect that.
    – Tobi Nary
    Mar 25, 2016 at 9:22
  • @SmokeDispenser - thanks, more on target. Smartcard (more secure/costs more): I prefer that within limits as it's a family member's LAN and we try to take security fairly seriously so far as able. Testing/revoke: how would we know if key/cert compromised? That's the big worry in all this. But if we know, they won't need revocation, I pull the router PSU+HD on the spot, phone them, then delete the entire router and reinstall + "known good" config + create all new key pairs/certs from scratch. There is no-one "reporting"/"to punish", and just one "client". Scenario now clarified, see Q update
    – Stilez
    Mar 25, 2016 at 14:02
  • OP, if you are planning on effectively abandoning the whole CA upon compromised CA, you may as well use a USB stick;) an example of compromise would be: you come to know that the client put the private key in a Dropbox or a untrustworthy machine.
    – Tobi Nary
    Mar 25, 2016 at 14:06
  • @AndréBorie - A good idea and likely to be well received. Without seeking specific product suggestions or drawing the main body of the question on a narrow tangent, a smartcard sounds a very good additional measure. We'd need maybe 2 for the owner and myself. What criteria might one look for, in such a simple situation where the need is good quality/security and trustworthy firmware writing/authorship/security updates for the hardware+driver, but other typical corporate needs are probably mostly irrelevant? And what vulnerabilities might be hopefully reduced/eliminated by using one?
    – Stilez
    Mar 25, 2016 at 14:09
-1

Use OpenVPNs bundled easyRSA scriptset and keep your CA private key on a USB stick. Also - NEVER keep backups of the certificates you're giving to clients : just fire-and-forget. Feel free to ask further questions!

UPDATE: easyRSA is an automation based on a shell and Perl scripts to facilitate a regular tasks like generating CA's private and public keys, generating client keys and maintaining a certificate registries, also it can be revoked by using it. If you need to understand how exactly it's done - just open a scripts, they are really simple, collected and bundled just for convinience - no underhood magic! You can issue all those commands one by one by hand, but especially when you're not proficient with CA-like stuff you will likely make a mistake and hurt your certificate registry, so try to get familiar with easyRSA and dig deeper into their source codes - they are self-explainatory and not complex, you will see it with your own eyes and experience

8
  • That's a bit too much like "press the button and trust the magic" :) I'm after the underlying understanding for the question posed, rather than a "use this recipe and you won't have to worry". Sorry but this answer doesn't actually help, as I'm not after a "howto" recipe or necessarily the easiest answer, so much as a good and useful explanation to help me draw conclusions and check what I need to know.
    – Stilez
    Mar 24, 2016 at 21:57
  • You might be mixing up key pairs and certificates which indicates you might have some reading up left to do on the topic. Also, keys shouldn't be generated by the CA; instead, the key holders should send a CSR. I'll make sure to come back tomorrow with fresh votes to downvote this.
    – Tobi Nary
    Mar 24, 2016 at 21:58
  • @SmokeDispenser actually for OpenVPN certificate management you have an easyRSA, and for shared TLS key and DHparams you have a one-line commands to generate. When I mean key here I mean only client- and server-srelated private+public pair managed by easyRSA. You can expand it's usage by adding some options to easyRSA's openssl.cnf and - if you need one-file certificate you can make dot-p12 file or dot-crt file. As you wish it to use Mar 24, 2016 at 22:07
  • @AlexeyVesnin - Thanks for trying but these are missing the point. i'm not asking for how to create them (technical/script). I'm asking about the security implications and practices in holding the "keys to the fortress" as the LAN's local CA and manager of its router and certificate system, a role completely new to me. One is technical, the other is security experience/_savoir-faire_ - "use/read the script" will never tell anyone this, and "how to generate" wasn't asked.
    – Stilez
    Mar 25, 2016 at 12:57
  • @SmokeDispenser ** - I probably have further reading to do, the confusion of terms is probably because in this case the CA would be the same person as the key holder, as I'll be managing both roles. I have clarified the scenario above to make "who's doing what" a bit clearer, if that helps.
    – Stilez
    Mar 25, 2016 at 13:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .