La mejor ubicación para el certificado SSL y las claves privadas en Ubuntu

En Ubuntu, parece que el mejor lugar para una clave privada utilizada para firmar un certificado (para uso de nginx) es /etc/ssl/private/

Esta respuesta agrega que el certificado debe entrar /etc/ssl/certs/pero que parece un lugar inseguro. ¿Los .crtarchivos deben mantenerse seguros o se consideran públicos?

El archivo .crt se envía a todo lo que se conecta; Es público. ( chown root:rooty chmod 644)

Para agregar a la ubicación de clave privada; asegúrese de asegurarlo correctamente y de tenerlo allí. ( chown root:ssl-certy chmod 640)

Realmente no importa dónde los coloque siempre que proteja adecuadamente sus archivos de clave privada . El certificado público es público; no se necesita protección - privilegios del servidor o de otra manera

Para ampliar la respuesta, no uso la ubicación predeterminada /etc/ssl.
Es más fácil para mí mantener todas las minas en un área separada debido a las copias de seguridad + otras razones.

Para Apache SSL, mantengo el mío en /etc/apache2/ssl/private"área raíz" similar /etc/.

Configuración de ejemplo

Esta publicación está orientada a Ubuntu (Debian) + Apache, pero debería funcionar en la mayoría de los sistemas:
solo aplique los permisos y actualice la ubicación / ruta en la configuración dada (apache / nginx / etc.).
Si los archivos de clave SSL están protegidos correctamente (directorio y archivos), estará bien. Tenga en cuenta las notas!

Crear directorios:

sudo mkdir /etc/apache2/ssl
sudo mkdir /etc/apache2/ssl/private
sudo chmod 755 /etc/apache2/ssl
sudo chmod 710 /etc/apache2/ssl/private

Nota:
chmod 710admite ssl-certgrupo bajo Ubuntu. (Ver comentarios)
Ajuste de permiso para 700el /etc/apache2/ssl/privatetambién funcionará bien.

Colocar archivos SSL:

Ponga certificado (s) público (s) de SSL junto con certificado (s) intermedio (s) en /etc/apache2/ssl
Ponga clave (s) privada (s) en/etc/apache2/ssl/private

Propietario del set:

sudo chown -R root:root /etc/apache2/ssl/
sudo chown -R root:ssl-cert /etc/apache2/ssl/private/

Nota:
Si no tiene el grupo ssl-cert , simplemente use 'root: root' en la línea de arriba u omita la segunda línea.

Establecer permisos:

Certificado (s) Público (s)

sudo chmod 644 /etc/apache2/ssl/*.crt

Clave privada (s)

sudo chmod 640 /etc/apache2/ssl/private/*.key

Nota:
El permiso de grupo está establecido en READ (640) debido al grupo ssl-cert de Ubuntu. '600' también está bien.

Habilite el módulo Apache SSL

sudo a2enmod ssl

Edite los archivos del sitio Apache y habilite

(ver último párrafo) *

sudo nano /etc/apache/sites-available/mysiteexample-ssl.conf
sudo a2ensite mysiteexample-ssl
#             ^^^^^^^^^^^^^^^^^ <-Substitute your ".conf" filename(s)

Reiniciar el servicio Apache2

sudo service apache2 restart

o

sudo systemctl restart apache2.service

Hecho. Prueba tu nuevo sitio SSL.

* Nuevamente, esto va más allá de la pregunta, pero puede copiar el archivo de configuración predeterminado del sitio Apache SSL ( sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/mysiteexample-ssl.conf) como un buen punto de partida / ejemplo de directivas / directorios predeterminados que normalmente se usan bajo un simple archivo 'conf' de Apache / SSL (Ubuntu / Debian) . Normalmente apunta a un certificado SSL autofirmado + clave (snakeoil), paquetes CA, así como directivas comunes utilizadas para un sitio SSL dado.

Después de copiar, simplemente edite el nuevo archivo .conf y agréguelo / elimínelo / actualícelo según sea necesario con la nueva información / rutas anteriores y luego ejecútelo sudo a2ensite mysiteexample-sslpara habilitarlo.

Todas las respuestas aquí parecen estar bien, pero quiero mencionar una cosa que encontré que es un problema ... Si tiene que concatenar su certificado con intermedios o raíces para obtener un archivo en cadena, no lo ponga /etc/ssl/certs, porque cuando c_rehashse ejecuta, puede crear enlaces simbólicos hash a sus certificados debido a las raíces o intermedios dentro de ellos.

Luego, más adelante, si sus certificados han caducado y los elimina, y no sabe volver a ejecutarlos c_rehash, es posible que haya roto los enlaces simbólicos en su /etc/ssl/certsdirectorio, y cosas extrañas comienzan a suceder cuando su máquina local intenta conectarse a sí misma a través de SSL, y no puede encontrar las raíces para validar. Por ejemplo, con curl de repente comencé a obtener:

curl: (60) SSL certificate problem: unable to get issuer certificate

Poco después de limpiar algunos viejos archivos .crt y .pem concatenados que tenía /etc/ssl/certs.

Almacenar al menos sus cadenas en otro lugar evita este problema. Terminé haciendo un /etc/ssl/local_certspara mantener mis certificados y cadenas, para que no se perdieran en el desastre de los certificados de CA que encontrarás en/etc/ssl/certs

Realmente no hay un lugar inseguro si el permiso para los archivos / directorios individuales está configurado en algo así chown root :0 private.keyy chmod 600 private.keysolo la raíz puede leerlo. Las CSR y los archivos de certificado son menos confidenciales como usted dice.

Con esos permisos, las rutas que menciona y / usr / local / ssl deberían estar bien.

Las ubicaciones son correctas:

• /etc/ssl/certs/para .crtarchivo
• /etc/ssl/privatepara .keyarchivo

El propietario debe ser root:rootpara ambos (use sudo chmod root:root <file>para cambiar si es necesario).

Permisos :

• 644para .crtarchivo
• 600para .keyarchivo

Esto funcionará para nginx.