Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Delivering mail to folders



> From: jabr at gapps.blu.org [mailto:jabr at gapps.blu.org] On Behalf Of John
> Abreau
> 
> Apparently I've been doing it "wrong" all these years. I've always created my
> own CA and signed my certificates with it, and I thought that's what the term
> "self-signed" meant.

That's the opposite of "doing it wrong."

If you create a CA, for example by a process like this: http://www.freebsdmadeeasy.com/tutorials/freebsd/create-a-ca-with-openssl.php in which you have a CA root private key, which signs itself as a CA, and you keep that directory full of files sitting around someplace secure, and the root private key is used only for signing certs (is not used directly as a website cert), and you generate a different private key for each website cert, and then you install the CA root cert (with public key) into the trusted root store of your clients... Then you've done it exactly right. (Assuming proper implementation choices, such as key length and stuff like that). But this process is complex enough that very few people do it, especially when you can get free certs from a publicly recognized CA.

When people say they have a webserver with a self-signed cert, in virtually all cases, that means they followed a process like this (the top result I got by searching for "generate self signed certificate"): http://www.akadia.com/services/ssh_test_certificate.html  In this process, you generate a key, and use that key to sign a certificate of itself. There was never any CA.

A good clue to look for is whether or not the "openssl ca" command was used, and if the CA root cert is separate and distinct from the server cert. The CA root private key should never exist on any of the servers. It should be air-gapped, encrypted, kept in a bank vault.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org