Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
archive/domain/privkeyN.pem is set to 0644 instead of 0600 (or 0440) #1473
changed the title
archive/domain/privkeyN.pem is set to 0644 instead of 0600 (or 0640)
Nov 18, 2015
This was referenced
Dec 4, 2015
referenced this issue
Dec 8, 2015
Since ~2006, Debian-based distros come along with a system group
For symlinks from /etc/ssl/..., something like this would be nice:
These settings should be fine for e.g. Debian 8 / Apache and many other applications.
I guess that users have different requirements (e.g. according to distro), so I think the permissions should be configurable via
I also want to note that wrong permissions (in the sense of user's requirements) cannot necessarily be healed by a later user interaction: Once the private key is readable after being written to disk with weak permissions, it could theoretically be stolen if the admin user changes permissions too late. Therefore, an emtpy file with correct file permissions must be written to disk before key material is written into the file.
I suggest to introduce three config values for
Optionally, this could also be done for public key material (just for completeness).
I'm not sure for other distros than Debian, if there is a
I guess the Debian package maintainers might want to go for
Courier Mailserver is complaining when LE's public certificates are symlinked from
Result: Courier only receives mail from some mailservers (I assume servers not supporting encryption). This even happens while I don't use LE certs for my mail server host name (yet). Courier has its own certificates stored in
The reason for that is that
To mitigate such issues and still be able to symlink the latest public certificate, the directories
With these permissions, symlinks to LE's public certificates would be world readable (which is fine for public certificates) while private certificates would be readable to only root and a configurable group, e.g.
This issue also makes trouble for samba - our domain controller uses certbot for certificates, and the
I really don't see why the permissions aren't just set properly in the first place (even though the directory is "safe" with
It's a bit strange that the code which originally generates the key, in https://github.com/certbot/certbot/blob/master/certbot/crypto_util.py#L65, already does the right thing (it uses open mode 0600, which is perfectly appropriate for private keys), and there is even a
In my opinion, 0600 is the right default mode for any private key material, and you should really use that. If e.g. Debian or another distro wants to introduce separate 'ssl-cert' groups with additional permissions, then they can patch their copy of certbot while packaging. I don't think it is up to upstream to cope with all the distro-specific variations.
The following diff should make >95% of people happy (and I'm applying it locally anyway):
Did a review of all of the concerns and proposed solutions in this thread. Here's a summary, interspersed with some concerns and some steps forward for the short-term.
There's a couple different things folks on this thread are concerned with:
...and also other things, but these are the three main ones.
1 & 2: private & public key permissions
There are a couple of complete solutions that would be nice to knock out all of these at once, like this directory permissioning recommendation from @thomaszbz. However, if we do this, or any similar proposal, we run the risk of exposing private key material if Certbot downgrades.
Currently, it's a fairly common workflow to downgrade versions of Certbot (e.g. use
For now, there's no reason we can't still knock out problem 1 in a simple and entirely safe way by dropping key permissions to 600 (basically @DimitryAndric's proposal), and punt this larger discussion to later.
3: Group permission configurability for private keys
I'd prefer some limited functionality like
We're also talking about this more this week, so this post/thread might be updated with more developments in the very near future.
This was referenced
Oct 30, 2018
referenced this issue
Nov 7, 2018
radicale needs +x to 'read' certificates (?); if certs are just +r, radicale.log yelds
g+rx on pem files fixes this error
added a commit
Nov 29, 2018
If you need a custom permission set on your private key: Starting with the next release, if you alter the GID or group mode of
When you create a new certificate, the permission is set by default to 0600.
The primary issue (as indicated in the title) is fixed. Further discussion setting group permissions for private key material as a command-line option, an adjacent issue, should continue in this issue #2964.
That seems like a good solution for everyone. Just two questions:
Edit: If I understand the commit correctly the change is behavior group-specific so permissions for "other" will NOT be retained.
It seems like the new version will always set the "world" permission bits to 0 (no permission). This might be a breaking change for some. Was this a deliberate decision?
Edit 2: Maybe my last question would be better placed in the pull request's comments (PR #6480)?
Thinking a bit more about this I came to the conclusion that this will be a breaking change for many users relying on the old behavior: Previously there was no way to retain file GID/permission on renewals.
Now if I understand the change correctly (and that might be a big IF) certbot will set the "world" permissions to 0. In that case the key is not accessible anymore in the scenario above.
To avoid breaking any setups I think certbot must also keep the "world" permissions on renewal.
Yes I confirm, private key world permissions will be set to 0, I have migrated the integration test and the assertion about one hour ago ^^
And the group permission also, by default, on new certificates. However, if afterward the group permission or the group owner is modified, it will be retained for any private key generated during the renewal.
So there will be a problem only for non-root processes outside of this group that relies on world readable permissions on private key to read it. Is it really a case? For what I know, most daemon processes are running as root, or fork themselves to an unprivileged user after setup as root.
And after, even if it is breaking change, it is, for that matter security, a sufficient reason to take the risk and remove the flaw in my opinion.
One notable example which comes to mind is Exim which reads the private key at runtime (under the "exim" user).
I agree that the change in itself is good but the previous setup was not insecure by itself so I don't like breaking existing setups - especially because most users will have automated renewals so something will go wrong in the middle of the night and monitoring will wake up some some poor sysadmin who needs to fix this in a frenzy.
@FelixSchwarz You're right, that setup would break on renewal. I'll work on something to remedy this (the simple solution being to preserve the other-read bit, or maybe a more complicated solution) today.
Sydney and I talked about this a bit out of band. The reason why at least I am not too worried about copying over the other read permission is that the key permissions are irrelevant from a security perspective as long as the permissions on
I also think this is a clear improvement to the state of things. Currently, private keys are always made world readable. With the change Sydney is proposing, the default will be that new lineages are created with keys with 600 permissions and that will be preserved between renewals unless the user makes changes to the permissions on the keys. In that case, we'll preserve the group, group permissions, and other read bit.
I think we agree that correct long term solution requires changes to the directory structure of
That's true. Preserving the other permission removes a second layer of protection that could help users from shooting themselves in the foot. That layer doesn't exist in any released version of Certbot so there's no harm there, however, it existed in the initial proposal for the change here and now we're removing it.
I appreciate you thinking about the problem though! I think it'll be a bit tricky, but I'd be happy to chat or hear a proposal for how to really solve the permission problems with certs and keys in the future.