Wie mache ich eine https-Anfrage mit einem schlechten Zertifikat?

Angenommen, ich möchte https://golang.orgprogrammatisch werden. Derzeit hat golang.org (ssl) ein schlechtes Zertifikat, das an *.appspot.comSo ausgestellt wird, wenn ich dies ausführe:

package main

import (
    "log"
    "net/http"
)

func main() {
    _, err := http.Get("https://golang.org/")
    if err != nil {
        log.Fatal(err)
    }
}

Ich bekomme (wie ich erwartet hatte)

Get https://golang.org/: certificate is valid for *.appspot.com, *.*.appspot.com, appspot.com, not golang.org

Jetzt möchte ich diesem Zertifikat selbst vertrauen (stellen Sie sich ein selbst ausgestelltes Zertifikat vor, mit dem ich Fingerabdrücke usw. validieren kann): Wie kann ich eine Anfrage stellen und das Zertifikat validieren / vertrauen?

Ich muss wahrscheinlich openssl verwenden, um das Zertifikat herunterzuladen, es in meine Datei zu laden und tls.Configstruct zu füllen !?

Sicherheitshinweis: Das Deaktivieren von Sicherheitsüberprüfungen ist gefährlich und sollte vermieden werden

Sie können Sicherheitsüberprüfungen global für alle Anforderungen des Standardclients deaktivieren:

package main

import (
    "fmt"
    "net/http"
    "crypto/tls"
)

func main() {
    http.DefaultTransport.(*http.Transport).TLSClientConfig = &tls.Config{InsecureSkipVerify: true}
    _, err := http.Get("https://golang.org/")
    if err != nil {
        fmt.Println(err)
    }
}

Sie können die Sicherheitsüberprüfung für einen Client deaktivieren:

package main

import (
    "fmt"
    "net/http"
    "crypto/tls"
)

func main() {
    tr := &http.Transport{
        TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
    }
    client := &http.Client{Transport: tr}
    _, err := client.Get("https://golang.org/")
    if err != nil {
        fmt.Println(err)
    }
}

Hier ist eine Möglichkeit, dies zu tun, ohne die Standardeinstellungen von zu verlieren DefaultTransportund ohne die gefälschte Anfrage gemäß Benutzerkommentar zu benötigen.

defaultTransport := http.DefaultTransport.(*http.Transport)

// Create new Transport that ignores self-signed SSL
customTransport := &http.Transport{
  Proxy:                 defaultTransport.Proxy,
  DialContext:           defaultTransport.DialContext,
  MaxIdleConns:          defaultTransport.MaxIdleConns,
  IdleConnTimeout:       defaultTransport.IdleConnTimeout,
  ExpectContinueTimeout: defaultTransport.ExpectContinueTimeout,
  TLSHandshakeTimeout:   defaultTransport.TLSHandshakeTimeout,
  TLSClientConfig:       &tls.Config{InsecureSkipVerify: true},
}

AKTUALISIEREN

Kürzere Art:

customTransport := &(*http.DefaultTransport.(*http.Transport)) // make shallow copy
customTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

Richtiger Weg (ab Go 1.13) (siehe Antwort unten ):

customTransport := http.DefaultTransport.(*http.Transport).Clone()
customTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

Warnung : Nur zu Test- / Entwicklungszwecken. Alles andere erfolgt auf eigenes Risiko !!!

Alle diese Antworten sind falsch! Verwenden Sie diese Option nicht InsecureSkipVerify, um mit einem CN umzugehen, der nicht mit dem Hostnamen übereinstimmt. Die Go-Entwickler waren unklug darauf bedacht, Hostnamenprüfungen (die legitime Verwendungszwecke haben - Tunnel, Nats, freigegebene Clusterzertifikate usw.) nicht zu deaktivieren, während sie auch etwas hatten, das ähnlich aussieht, die Zertifikatsprüfung jedoch vollständig ignoriert. Sie müssen wissen, dass das Zertifikat gültig und von einem vertrauenswürdigen Zertifikat signiert ist. In gängigen Szenarien wissen Sie jedoch, dass der CN nicht mit dem Hostnamen übereinstimmt, mit dem Sie verbunden sind. Für diejenigen, setzen Sie ServerNameauf tls.Config. Wenn tls.Config.ServerName== remoteServerCN, ist die Zertifikatprüfung erfolgreich. Das ist, was du willst. InsecureSkipVerifybedeutet, dass KEINE Authentifizierung vorliegt; und es ist reif für einen Mann in der Mitte; den Zweck der Verwendung von TLS zunichte machen.

Es gibt eine legitime Verwendung für InsecureSkipVerify: Verwenden Sie diese Option, um eine Verbindung zu einem Host herzustellen, dessen Zertifikat abzurufen und die Verbindung sofort zu trennen. Wenn Sie Ihren Code für die Verwendung InsecureSkipVerifyeinrichten, liegt dies im Allgemeinen daran, dass Sie ihn nicht ServerNamerichtig eingestellt haben (er muss von einem env var oder so stammen - machen Sie sich keine Sorgen um diese Anforderung ... machen Sie es richtig).

Insbesondere wenn Sie Client-Zertifikate verwenden und sich bei der Authentifizierung auf diese verlassen, haben Sie im Grunde eine gefälschte Anmeldung, die sich nicht mehr anmeldet. Verweigere Code, der es tut InsecureSkipVerify, oder du wirst auf die harte Tour lernen, was daran falsch ist!

Der richtige Weg, dies zu tun, wenn Sie die Standardtransporteinstellungen beibehalten möchten, ist jetzt (ab Go 1.13):

customTransport := http.DefaultTransport.(*http.Transport).Clone()
customTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}
client = &http.Client{Transport: customTransport}

Transport.Clone erstellt eine tiefe Kopie des Transports. Auf diese Weise müssen Sie sich keine Sorgen mehr machen, dass neue Felder fehlen, die im TransportLaufe der Zeit zur Struktur hinzugefügt werden.

Wenn Sie die Standardeinstellungen aus dem http-Paket verwenden möchten, damit Sie kein neues Transport- und Client-Objekt erstellen müssen, können Sie die Zertifikatüberprüfung folgendermaßen ignorieren:

tr := http.DefaultTransport.(*http.Transport)
tr.TLSClientConfig.InsecureSkipVerify = true

Im Allgemeinen MUSS die DNS-Domäne der URL mit dem Zertifikatsgegenstand des Zertifikats übereinstimmen.

In früheren Zeiten konnte dies entweder durch Festlegen der Domäne als cn des Zertifikats oder durch Festlegen der Domäne als alternativen Antragstellernamen erfolgen.

Die Unterstützung für cn war lange Zeit veraltet (seit 2000 in RFC 2818 ) und der Chrome-Browser wird den cn nicht mehr anzeigen. Daher müssen Sie heute die DNS-Domäne der URL als alternativen Betreff haben.

RFC 6125, der die Überprüfung des cn verbietet, wenn SAN für DNS-Domäne vorhanden ist, nicht jedoch, wenn SAN für IP-Adresse vorhanden ist. RFC 6125 wiederholt auch, dass cn veraltet ist, was bereits in RFC 2818 erwähnt wurde. Und das Browser Forum der Zertifizierungsstelle muss vorhanden sein, was in Kombination mit RFC 6125 im Wesentlichen bedeutet, dass cn niemals auf DNS-Domänennamen überprüft wird.