I am curious about what should be the file permission of the ssl certificate files. Because you really don't want anyone physically copying the server key, so why does the hosts make it readable to everyone? (644)
This is partially subjective and especially because your question lacks too many points of context like: which applications are using these certificates, which OS (based on your mention of
644 it seems you speak about Unix systems - in which case saying
rw-r--r-- seems far more readable to me - but there are other OS out there), which level of security, etc.
So let us go back a little. For typical HTTPS PKI operations a server needs to have one certificate (per virtual host typically) which is bascially the public part of a key and, separately, the private key file. We will often see these called: the certificate and the key.
Personal pet peeve diversion: stop saying "SSL certificate", even if everyone does it, as it is a double errors. First, SSL does not exist anymore, we do TLS nowadays. And then it is really a X.509 certificate used for TLS communications, as you could do TLS without certificates at all or TLS with other key materials than X.509 certificate, so these two things are independent in fact.
The certificate is public by definition. So it can be made available to anyone, that is "world readable". As any other file I would however make sure that it is not owned (nor the directory in which it resides) by the same UID under which the webserver runs.
As for the key, by definition, it is private. Its Unix rights should be as small as possible, based on other constraints. If it is owned by same UID as the webserver (not the case I recommend), it can be
r--------; otherwise a sensible option would be to make it owned by root or some other admin account and create a group for the webserver so that the rights could be