-
-
Notifications
You must be signed in to change notification settings - Fork 881
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix SSL cert and key permissions #119
Conversation
It is bad practice to use 644 on a private key so we have migrated the key mode to 0400. The cert is already avaliable publicly through nginx so we have allowed it 0444. Nothing should need to write either the cert of the key after puppet has run, so we have denied any writing.
Hello |
I'm not sure there's any benefit to using 0440 when the default group is "root". Other UID==0 processes will be able to read the file anyway. I'd venture that anything UID>0 and not Nginx should probably have it's own copy outside of Nginx's config dir. |
You can change group for private key. |
@dcarley let's go with |
I've push a commit to allow the key's group permission to read the file |
🤘 |
Fix SSL cert and key permissions
Is there a way for this module to have parameters like ssl_owner and/or ssl_mode? I see you've settled on www-data 400... but in my humble opinion, perms on private key must be root - 0400. This is just in case you server gets compromised somehow (i.e.: php shell); it is then not possible for any of your nginx processes to retrieve your private keys. This way, broken code somewhere in your application won't mean an attacker can decrypt your communications... or have you regenerate your expensive certs. Cheers! |
Fix SSL cert and key permissions
It is bad practice to use 644 on a private key so we
have migrated the key mode to 0400. The cert is already
avaliable publicly through nginx so we have allowed it
0444.
Nothing should need to write either the cert of the key
after puppet has run, so we have denied any writing.