# what permissions for ssl

## javeree

Yesterday, for the first time, I installed ssl keys and am using it now to provide https and imaps access.

However, since then, when I logon as a standard user, I get the following 

 *Quote:*   

>  * keychain 2.7.1 ~ http://www.funtoo.org
> 
>  * Found existing ssh-agent: 6091
> 
> Auto configuration failed
> ...

 

I don't know why or how keychain tries to access '/etc/ssl/openssl.cnf', but the problem with the permission denied is:

drwx------ 5 root root 4096 18 feb 17:41 /etc/ssl

I could chmod 744 /etc/ssl, but that would mean anyone can then access /etc/ssl, including the keys within. At best I could limt it to a certain group of users (but in practice it would result in all 'standard' users).

Since I have just followed a few recipes to create the keys, I have limited understanding of what each file is. I wanted to know what files I can leave world readable and which ones must be root only

At this moment I have (ls -l /etc/ssl/*)

 *Quote:*   

> -rw-r--r-- 1 root root 2325 17 feb 12:59 /etc/ssl/cacert.pem
> 
> -rw-r--r-- 1 root root  173 17 feb 17:28 /etc/ssl/certindex.txt
> 
> -rw-r--r-- 1 root root   21 17 feb 17:28 /etc/ssl/certindex.txt.attr
> ...

 

I assume that it is sufficient to 

chmod 700 /etc/ssl/private/* but don't know about the other files.

FYI, the 'recipe' used was

 *Quote:*   

> SSLDIR="/etc/ssl"
> 
> mkdir "$SSLDIR"
> 
> chmod 0700 "$SSLDIR"
> ...

 

I believe the /etc/ssl/dovecot directory is the result of an earlier attempt. Should I be able to delete that ?

----------

## Hu

 *javeree wrote:*   

> I could chmod 744 /etc/ssl, but that would mean anyone can then access /etc/ssl, including the keys within. At best I could limt it to a certain group of users (but in practice it would result in all 'standard' users).

 No, it would not.  Mode 744 would permit users to list the directory contents, but not to open the files within.

 *javeree wrote:*   

> Since I have just followed a few recipes to create the keys, I have limited understanding of what each file is. I wanted to know what files I can leave world readable and which ones must be root only

 Protect files which contain private keys.  You may protect files which contain public keys, but that is not required.

 *javeree wrote:*   

> I assume that it is sufficient to 
> 
> chmod 700 /etc/ssl/private/* but don't know about the other files.

 Generally, you do not need to grant execute permission to keys.

----------

## javeree

@Hu

Thanks,

yes of course, 744 on a directory would not necessarily mean the user can read files within, but with the files within being 644, it would be possible. That was what I meant: If I set directory to 744, for which files do I need to switch off the world or group reading rights.

I've tried yesterday to understand better what is behind the recipe I found, and together with your comments, I did the following.

I suppose all files in /etc/ssl/private are (drumroll) ... private keys. So I allow access to root only 700 on the dir and 600 on the keys within.

I found out that the dovecot directory is created by the dovecot ebuild. So I just deleted that

I believe that the /etc/ssl/certs directory is meant to store trusted keys. So it is not necessary for the server side, but for the client side. It only contains keys that are public (my keys and public keys from others), so I should set dir and files to read only, as I don't want anyone to tell the system who to trust.

All pem files in /etc/ssl are public, so read-only is fine. 

(I wonder if it is allowed to remove the -request files ?)

Finally the certindex* and openssl.cnf files. These also don't contain secrets, so read only is allowed.

I've updated the settings as above.

----------

## Hu

 *javeree wrote:*   

> yes of course, 744 on a directory would not necessarily mean the user can read files within, but with the files within being 644, it would be possible. That was what I meant: If I set directory to 744, for which files do I need to switch off the world or group reading rights.

 You misunderstood my statement.  If you set the directory to mode 744, then you do not need to protect any of the files because only the directory owner has search permission on the directory.

----------

