sysadmin/WhyFirewall written at 22:13:35; Add Comment
Four reasons to have a firewall
Recently I ran across someone asking the question 'why have a firewall?' As it turned out, he had several sorts of host-based firewall protection, but in thinking about the question I came up with four broad reasons that firewalls can be a good idea:
Whether to use host-based firewalls or an external firewall is an implementation decision, but I tend to think that an external firewall is more reliable and simpler to configure and keep straight (if you have a non-trivial internal architecture of what is where and who can talk to it and so on). Of course it is also a single point of failure, as the no-firewall people keep reminding us, so the right thing to do is to have both well protected hosts and an external firewall.
tech/SSLChainOrder written at 00:32:00; Add Comment
The ordering of SSL chain certificates
SSL certificates for hosts are usually not directly signed by your CA's trust root certificate, the certificate that is in your browser, your mail client, or whatever. Instead there is generally at least one intermediate certificate (sometimes several), and in order for clients to accept your host certificate you need to send them not just the host certificate but also all of the intermediate certificates in the chain of signatures between you and the CA trust root.
How you configure this depends on the server software, with two general
approaches. Apache (well, mod_ssl) lets you specify a certificate
chain file separate from your certificate itself; you put your
All of which raises a question: if you're putting several certificates in one file, what's the right order for them and does it matter?
The correct order turns out to be the host certificate first, then the
certificate that signs it, then the certificate that signs the previous
certificate, and so on for as many levels as you need. Basically, the
most specific certificate to the least specific certificate, with each
certificate verifying the previous one. Certificates are plain ASCII
(with a variety of extensions,
(This tends not to be clearly documented in the instructions for various software (which tends to assume that you are already an SSL expert), but can be dug out of the TLS RFC with enough determination.)
In practice the order doesn't seem to matter. As you might expect, common clients will accept and verify both out of order certificate chains and certificate chains with unnecessary and unused certificates.
(Clients like browsers and IMAP mail clients have a strong motivation to do so, given that server operators get this wrong with reasonable frequency. Other clients may be more picky and paranoid, generally to no real advantage.)
(This is the kind of entry that I write so that I have a chance of remembering this the next time I care about it.)
Sidebar: why you might have unused certificates in a chain file
Suppose (not entirely hypothetically) that your SSL certificate vendor issues certificates that are signed by a number of different intermediate certificates, depending on the specific circumstances where you got them. If you want to deploy certificates without having to look up exactly which intermediate certificate your CA used, the easy thing to do is to throw them all into a single universal certificate chain file. Then you just install the server certificate and the chain file (concatenating the two of them together for things like Exim) and are done with it.
* * *
Atom feeds are available; see the bottom of most pages.