Am 24.10.2014 um 18:31 schrieb Valeri Galtsev <galtsev@xxxxxxxxxxxxxxxxx>:
>
> On Fri, October 24, 2014 10:43 am, Timothy Murphy wrote:
>> A very ignorant question, sans doute.
>>
>> I get my certificates from cacert.org, to whom I am very grateful.
>> I follow what I take to be the official procedure,
>> first creating <server>.key and <server>.csr on my server
>> and then getting <server>.crt by going to Server Certificate=>New
>> at the cacert site.
>>
>> I then place the key certficate *.key in /etc/pki/tls/private/
>> and what I call the client certificate *.crt in /etc/pki/tls/certs/ .
>>
>> But I notice that there at www.cacert.org there is
>> a Client Certificate folder as well as the Server Certificate folder,
>> and it seems that one can create a "client certificate" there.
>
> In two words: some of the stuff you would only serve to clients that
> authenticate themselves. Well known way of authentication is:
> username/password. Client certificate serves the same purpose, it is just
> less known way of doing it.
conceptional that means that the former is something that you
known and the latter is something that you have (+ known), to
authenticate yourself.
>>
>> My quesion is: what is the purpose of this second client certificate?
>>
>> And while I am on the topic, what are the recommended file permissions
>> for PKI certificates?
>> I was a little surprised to find my <server>.key has permission 640,
>> while <server>.crt has permission 644.
>> The folder /etc/pki/tls/private/ on my server
>> does not seem to have any special security;
>> it is owned by root but can be opened and listed by anybody.
>> Is that the recommended setup?
>>
>
> For secret key I usually have 400 (-r-------). For Certificate, it doesn't
> matter that much: your server passes it over to anyone who requests it at
> the very beginning of SSL/TLS connection. I still keep it without write
> permission. You only change certificate/key once every year or two, so you
> don't need write permission for these files in general...
>
> Note that if some daemon needs secret key and it is not designed to start
> as root (to read the key...) then drop privileges, then you will have to
> make secret key group readable, grant it to appropriate group, and make
> sure the poor daemon who can not start as root first is a member of that
> group.
and keep your key/cert-pair out of your system backups.
--
LF
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
