Posted by
michael
on from the snake-oil-enterprises dept.
lisam writes "Rob Flickenger shows how to become your own Certificate Authority, and sign your own, or others', SSL certificates in this onlamp.com article. (He also manages to mention fnords and deny responsiblity for the Microsoft Corporation cert snafu.)"
While I frequently find valuable information in Oreilly's articles, such as this one,
this one is nothing but fluff; purely a plug for the author's book.
The exact info is available in the docs that come with OpenSSL, as well as in the OpenSSL animal book.
Re:This is important, but...
by
Breakerofthings
·
· Score: 2, Informative
Reasonable in that it is easiest, yes.
Reasonable that it is the most financially viable option, not necessarily. Not if you need a *lot* of certificates, like I do.
Reasonable, to pay VeriSign's extortion? No. No on principle.
There is no loss of encryption in not using an "big boy" (which I mean to be an established CA). My ssl is just as secure, in terms of encryption. My only disadvantage is that my visitors have to trust that I am me; I don't have to have VeriSign vouch for me. Arguably, since my CA private cert is in a safe, I am *more* secure, cause I don't have to worry about Verisign F-ing up like they did with MS.
I was hoping they went further
by
Gerry+Gleason
·
· Score: 2, Informative
Pretty disappointing. Anyone at/. that is interested in CAs and such should already be aware that OpenSSL has all the functions for manipulating the various file formats involved if you have the time to grok the command line interface to all of this.
I can give you more help right here and clear up some stuff they glossed over. First, a certificate is not a public key, but it includes the public key, and it is signed by the private key of the Certificate Authority (CA). In the example, a 'root' or self-signed certificate is created. The private key is typically password protected when it is stored (you can see it prompting for that password in the script).
He doesn't show you what you have to do to create the '.csr' file that is used to create the actual site certificate, but this is what is called the Certificate Request. Also, the '.key' file should be created in a separate step. The process is that when someone wants a certificate, they generate a request on their computer that includes all the 'name' information (as displayed in article) and the public key. The private key is generated at the same time, but it should never leave the site generating the request, and additional steps should be taken to protect it from being exposed. The article implies that the key pair is generated by the command given, but I don't think it is (a separate step is needed to create the.csr file, and it should be created then).
A few more notes: your new '.crt' (the certificate) file will show up in 'newcerts' (if not, then 'certs'), the 'serial' file is the serial number of the next (or last) cert issued, and the 'crl' subdir is for the "Certificate Revocation List" all CAs should have one, and it should list all the certificates issued by this authority that have been revoked (by serial number, I think). AFAIK, this is the biggest hole in the process. To correctly verify the validity of a cert, you should always check the cert's serial number against the CRL, but where to you get the CRL? There must be a standard way to get the current CRL from a CA, but does a browser or other client have any function to get it before validating a certificate? Nothing I've seen indicates that clients do this so I doubt whether revocation is ever effective in a practical sense.
Now, what would be really cool is if someone wrapped the functions to create a certificate request with a few web pages and provided a howto describing how to set this up and really run your own CA. If I was doing it, I would keep the CAs private key on external media (a floppy or CD/R), and only put it in the system when I need it to sign certs and CRLs. Isolating the system you use for this is better, but you do still have to get the requests in and the certs or CRLs out.
One final comment. It is just about impossible to actually protect the private key for a typical web server. Or at least protect it from root exploits. This is because you have to either not use a password so that your web server can restart without a password, or have some script that provides the password on startup of the web server. The only other choice is to have someone actually type it whenever a server needs to be restarted, and I don't have to point out here what a pain this would be for a big server farm.
Slashdot Mirror
While I frequently find valuable information in Oreilly's articles, such as this one, this one is nothing but fluff; purely a plug for the author's book. The exact info is available in the docs that come with OpenSSL, as well as in the OpenSSL animal book.
Reasonable in that it is easiest, yes. Reasonable that it is the most financially viable option, not necessarily. Not if you need a *lot* of certificates, like I do. Reasonable, to pay VeriSign's extortion? No. No on principle. There is no loss of encryption in not using an "big boy" (which I mean to be an established CA). My ssl is just as secure, in terms of encryption. My only disadvantage is that my visitors have to trust that I am me; I don't have to have VeriSign vouch for me. Arguably, since my CA private cert is in a safe, I am *more* secure, cause I don't have to worry about Verisign F-ing up like they did with MS.
I can give you more help right here and clear up some stuff they glossed over. First, a certificate is not a public key, but it includes the public key, and it is signed by the private key of the Certificate Authority (CA). In the example, a 'root' or self-signed certificate is created. The private key is typically password protected when it is stored (you can see it prompting for that password in the script).
He doesn't show you what you have to do to create the '.csr' file that is used to create the actual site certificate, but this is what is called the Certificate Request. Also, the '.key' file should be created in a separate step. The process is that when someone wants a certificate, they generate a request on their computer that includes all the 'name' information (as displayed in article) and the public key. The private key is generated at the same time, but it should never leave the site generating the request, and additional steps should be taken to protect it from being exposed. The article implies that the key pair is generated by the command given, but I don't think it is (a separate step is needed to create the .csr file, and it should be created then).
A few more notes: your new '.crt' (the certificate) file will show up in 'newcerts' (if not, then 'certs'), the 'serial' file is the serial number of the next (or last) cert issued, and the 'crl' subdir is for the "Certificate Revocation List" all CAs should have one, and it should list all the certificates issued by this authority that have been revoked (by serial number, I think). AFAIK, this is the biggest hole in the process. To correctly verify the validity of a cert, you should always check the cert's serial number against the CRL, but where to you get the CRL? There must be a standard way to get the current CRL from a CA, but does a browser or other client have any function to get it before validating a certificate? Nothing I've seen indicates that clients do this so I doubt whether revocation is ever effective in a practical sense.
Now, what would be really cool is if someone wrapped the functions to create a certificate request with a few web pages and provided a howto describing how to set this up and really run your own CA. If I was doing it, I would keep the CAs private key on external media (a floppy or CD/R), and only put it in the system when I need it to sign certs and CRLs. Isolating the system you use for this is better, but you do still have to get the requests in and the certs or CRLs out.
One final comment. It is just about impossible to actually protect the private key for a typical web server. Or at least protect it from root exploits. This is because you have to either not use a password so that your web server can restart without a password, or have some script that provides the password on startup of the web server. The only other choice is to have someone actually type it whenever a server needs to be restarted, and I don't have to point out here what a pain this would be for a big server farm.