Vraag Beste locatie voor SSL-certificaat en privésleutels op Ubuntu


Op Ubuntu lijkt het de beste plaats voor een privésleutel die wordt gebruikt om een ​​certificaat te ondertekenen (voor gebruik door nginx). /etc/ssl/private/

Deze antwoord voegt eraan toe dat het certificaat moet worden ingeleverd /etc/ssl/certs/ maar dat lijkt een onveilige plek. Do .crt bestanden moeten veilig worden bewaard of worden ze als openbaar beschouwd?


53
2018-04-13 15:56


oorsprong


Je kunt je .crt op een billboard in Times Square, als je wilt. - ceejayoz


antwoorden:


Het .crt-bestand wordt verzonden naar alles dat verbinding maakt; het is openbaar. (chown root:root en chmod 644)

Toevoegen aan de privésleutellocatie; zorg ervoor dat je het goed vastzet en er ook in hebt. (chown root:ssl-cert en chmod 640)


44
2018-04-13 16:06



Ik vraag me af waarom die map standaard geen g + s is. - Collin Anderson
Het hoeft niet zo te zijn; de map is 0750, dus er is geen mogelijkheid voor gebruikers die niet in de groep zijn om door de directory te gaan om de bestanden te lezen. - womble♦
Voor de meeste toepassingen die ik gebruik, zie ik het gedrag zoals beschreven in het gekoppelde antwoord: ze gebruiken de gebruiker root om het certificaat te laden. Maar de permissies hier zijn goed uitgelegd. - SimonSimCity
Het lijkt erop dat ssl-cert een ongeldige groepsnaam is op ubuntu. Misschien moet het chown-root zijn: root in plaats daarvan - Atifm


Het maakt echt niet uit waar je ze neerzet, zolang je je maar goed beschermt prive sleutel file (s). De openbaar certificaat is openbaar; geen bescherming nodig - serverprivileges of anderszins.

Om het antwoord uit te breiden, gebruik ik de standaardlocatie niet /etc/ssl.
 Het is gemakkelijker voor mij om al de mijne op een ander gebied te houden vanwege back-ups + andere redenen.

Voor Apache SSL bewaar ik de mijne /etc/apache2/ssl/private of een soortgelijk "root gebied" in /etc/.

Voorbeeld instellen

Dit bericht is gericht op Ubuntu (Debian) + Apache, maar zou op de meeste systemen moeten werken -
 Pas de rechten toe en update locatie / pad in de gegeven config (apache / nginx / etc).
  Als de SSL-sleutelbestanden correct worden beschermd (map & bestanden), komt alles goed. Let op de opmerkingen!

Maak mappen:

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

Notitie:
chmod 710 ondersteuningen ssl-cert groep onder Ubuntu.
 (Zie Reacties)
Toestemming instellen voor 700 op /etc/apache2/ssl/private werkt ook goed. 

Stel eigenaar in:

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

Notitie:
Als je niet hebt ssl-cert groep, gebruik gewoon 'root: root' op regel hierboven of sla 2e regel over.

Plaats SSL-bestanden:

Leggen openbaar www ssl certificaat (en) samen met tussentijds certificaat (en) in     /etc/apache2/ssl
  Leggen privaat ssl-sleutel (s) in /etc/apache2/ssl/private

Rechten instellen:

Openbaar certificaat (en)

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

Private sleutel (s)

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

Notitie:
De groepstoestemming is ingesteld op READ (640) vanwege de Ubuntu-ssl-cert-groep. '600' is ook prima.

Schakel de Apache SSL-module in

sudo a2enmod ssl

Bewerk alle Apache-sitebestanden en schakel in

(zie laatste paragraaf) *

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

Start Apache2-service opnieuw

sudo service apache2 restart

of

sudo systemctl restart apache2.service

Gedaan. Test uw nieuwe SSL-site.

* Nogmaals, dit gaat verder dan de vraag, maar je kunt het standaard Apache SSL-site-configuratiebestand kopiëren (sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/mysiteexample-ssl.conf) als een goed startpunt / voorbeeld van standaardrichtlijnen / directory's die normaal worden gebruikt onder een eenvoudig (Ubuntu / Debian) Apache / SSL 'conf' bestand. Het verwijst normaal naar een zelfondertekend SSL-certificaat + sleutel (snakeoil), CA-bundels, en ook vaak richtlijnen gebruikt voor een bepaalde SSL-site.

Bewerk na het kopiëren het nieuwe .conf-bestand en voeg het toe / verwijder / update het naar behoefte met nieuwe informatie / paden hierboven en voer het uit sudo a2ensite mysiteexample-ssl om het in te schakelen.


32
2017-10-21 17:17



niet zeker waarom je zou voorstellen 710 in te stellen voor permissies voor / etc / apache2 / ssl / private. Het instellen van de execute bit voor de directory (voor de groep) zonder het lezen van bit voor de directory (voor de groep) in te stellen, heeft voor mij weinig zin. Bedoelde u om het in te stellen op 750? - chriv
@chriv Ik heb zojuist rechten ingesteld op basis van hoe ik het zie instellen onder Ubuntu standaard SSL-gebied. Zie / etc / ssl / certs & / etc / ssl / private & ssl-certs group use. Zien stackoverflow.com/a/23408897/503621 - bshea
Een zeer mooie en gedetailleerde uitleg voor een generieke vraag met veel mogelijke antwoorden. Dank je. Gewoon om een ​​paar dingen toe te voegen, jouw <VirtualHost *:443> sectie in uw sites-available/mysite.conf moet de certificaten als volgt bevatten: SSLEngine on  SSLCertificateFile /etc/apache2/ssl/mysite.crt  SSLCertificateKeyFile /etc/apache2/ssl/private/mysite.key - George Dimitriadis
Tussen haakjes - Het is ook mogelijk om uw: 80 en: 443 configs te combineren in één Apache ".conf" -bestand. Ik leid om het even wat door naar de poort: 80 naar: 443 / SSL. Het is ook mogelijk om basis SSL-instellingen in het .conf-bestand te plaatsen en een extra 'gedetailleerd' SSL-instellingenbestand te maken (bijvoorbeeld om gebruikte coderingen in te stellen / etc) en gewoon omvatten het in al uw .conf-bestanden buiten virtuele gebieden. Ik gebruik deze instellingen om SSL een beetje 'uit te harden' en ik neem het op elke virtuele site .conf op. Ik kan A + krijgen SSL Labs op deze manier . - bshea


Alle antwoorden lijken hier in orde, maar ik wil een ding vermelden dat ik heb gevonden is een probleem ... Als je je cert moet samenvoegen met tussenproducten of wortels om een ​​kettingbestand te maken, niet doen stop dat erin /etc/ssl/certs, omdat wanneer c_rehash wordt uitgevoerd, het kan hash-symlinks naar uw certificaten veroorzaken vanwege de wortels of tussenliggende elementen in de certificaten.

Later op de weg als uw certificeringen verlopen zijn en u ze verwijdert, en niet weet om opnieuw uit te voeren c_rehash, hebt u mogelijk hash-symlinks in uw /etc/ssl/certs directory, en er gebeuren vreemde dingen wanneer uw lokale machine via SSL verbinding probeert te maken met zichzelf en de wortels niet kunnen vinden om te valideren. Met krul kreeg ik bijvoorbeeld opeens:

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

Kort na het opruimen van enkele oude .crt en aaneengeschakelde .pem-bestanden die ik had /etc/ssl/certs.

Als u ten minste uw kettingen ergens anders opslaat, wordt dit probleem voorkomen. Ik heb uiteindelijk een gemaakt /etc/ssl/local_certs om mijn certs en kettingen te houden, zodat ze niet verloren gingen in de puinhoop van CA certs die je zult vinden /etc/ssl/certs


8
2018-03-23 14:58





Er is niet echt een onveilige plaats als de toestemming voor de individuele bestanden / map is ingesteld op iets als chown root :0 private.key en chmod 600 private.key zodat alleen root het kan lezen. CSR's en certificaatbestanden zijn minder gevoelig zoals u zegt.

Met die permissies zouden de paden die je noemt en / usr / local / ssl prima moeten zijn.


2
2018-04-13 16:08



Vaak worden toepassingen die toegang hebben tot persoonlijke sleutels, uitgevoerd als niet-rootgebruikers. Ik zou willen voorstellen om de toegang voor de ssl-cert-groep te behouden. - Shane Madden♦
Begrepen, maar webservers zoals Apache spawn een root 'parent' proces en uitgaande van nginx is dit ook relevant. - Jonathan Ross