Das SSL-CA-Zertifikat (Pfad? zugriffsrechte) auf Ubuntu 16?

Question

Das SSL-CA-Zertifikat (Pfad? zugriffsrechte) auf Ubuntu 16?

Problem mit dem SSL-CA-Zertifikat (Pfad? zugriffsrechte?). Ich habe ein SSL-Zertifikat von Commodo und es ist ok installiert. Alles scheint korrekt zu funktionieren und ich habe meinen Server und Apache2 neu gestartet.

Service apache2 status zeigt keine Fehler an.

Dies wurde verwendet:

sudo apt-get update && sudo apt-get upgrade -fy && sudo apt-get dist-upgrade -fy

Die Probleme, die ich online sehe, betreffen entweder Amazons Linux (mit yum) oder CentOS. Sie sagten, den Server neu zu starten. Ich benutze Ubuntu 16.04 und bin mir nicht sicher, was ich als nächstes tun soll?

Dies betrifft Pakete heruntergeladen werden, wie dieses Beispiel:

Ich habe versucht, einen Befehl auszuführen wie:

Ich habe einen Komponisten gemacht.json-Datei -

{
  "require": {
      "aws/aws-sdk-php": "3.*"
  }
}

Komponist installieren

[RuntimeException]
  Failed to clone https://github.com/jmespath/jmespath.php.git via https, ssh
   protocols, aborting.
  - https://github.com/jmespath/jmespath.php.git
    Cloning into '/var/www/ssl/s3/test/vendor/mtdowling/jmespath.php'...
    fatal: unable to access 'https://github.com/jmespath/jmespath.php.git/':
  Problem with the SSL CA cert (path? access rights?)
  - [email protected]:jmespath/jmespath.php.git
    Cloning into '/var/www/ssl/s3/test/vendor/mtdowling/jmespath.php'...
    Permission denied (publickey).
    fatal: Could not read from remote repository.

    Please make sure you have the correct access rights
    and the repository exists.

3

linux ssl certificate ubuntu apache-http-server

Author: DDJ, 2017-02-16

Source

4 answers

score 4 · Answer 1

Ich bin auf den SSL-Fehler git clone bei einer kleinen Debian-Distribution (unter Linux) gestoßen, und zwar deshalb, weil die Standard-Root-CAs nicht installiert waren, was bedeutet, dass git (und sogar einfache Dinge wie curl https://google.com) die SSL-Zertifikate von HTTPS-Sites nicht überprüfen konnten.

Die Lösung bei lxadm, die für mich funktionierte, bestand nur darin, ca-certificates zu installieren:

sudo apt install ca-certificates

score 3 · Answer 2

Meiner Meinung nach ist der SSH-Schlüssel in diesem Szenario nicht autorisiert, und Sie müssen einen öffentlichen SSH-Schlüssel erstellen und den Administrator des Git-Repositorys auffordern, den öffentlichen SSH-Schlüssel hinzuzufügen. Sie können unten URL für weitere Informationen verweisen:

Https://stackoverflow.com/questions/7430311/saving-ssh-key-fails/8600087#8600087

score 0 · Answer 3

Das hat bei mir funktioniert. Installieren eines Root / CA-Zertifikats. Gegeben eine CA-Zertifikatdatei foo.crt, folgen Sie diesen Schritten, um es auf Ubuntu zu installieren:

Erstellen Sie ein Verzeichnis für zusätzliche CA-Zertifikate in /usr/share/ca-Zertifikate:

sudo mkdir /usr/share/ca-certificates/extra

Kopiere die CA.crt-Datei in diesem Verzeichnis:

sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt

Lassen Sie Ubuntu die hinzufügen .pfad der CRT-Datei relativ zu /usr/share /ca-Zertifikaten zu/etc / ca-Zertifikaten.conf:

sudo dpkg-reconfigure ca-certificates

score 0 · Answer 4

Wir sahen intermittierende Fehler von git clone Befehlen in den Bereitstellungsskripten für eine Elastic Beanstalk Ubuntu 16-Instanz. Wenn die Fehler auftreten, wenn gerade eine neue Serverinstanz gestartet wurde, wird möglicherweise unattended-upgrades beim Booten als Ergebnis von apt.daily wie in dieser andere Thread besprochen und aktualisiert zufällig ca-certificates zum Zeitpunkt der Ausführung der Bereitstellungsskripte.

Wir haben ein neues Image mit den neuesten Sicherheitsupdates als erstes installiert schritt, der die intermittierenden Fehler löste und um das wiederkehrende Problem zu verhindern, folgte die Lösung von hier, die die Datei

/etc/systemd/system/apt-daily.timer.d/apt-daily.timer.conf

[Timer]
Persistent=false

Die persistent - Einstellung gibt es", um verpasste Läufe des Dienstes nachzuholen, wenn das System heruntergefahren wurde " gemäß dem - Systemd.timer-Manpage, so dass das Setzen auf false verhindert, dass die täglichen Aufgaben, einschließlich unattended-upgrades, beim Booten ausgeführt werden.