¿Cómo hacer una solicitud https con certificado incorrecto?

Digamos que quiero llegar https://golang.orgprogramáticamente. Actualmente golang.org (ssl) tiene un certificado incorrecto que se emite a *.appspot.comSo cuando ejecuto esto:

package main

import (
    "log"
    "net/http"
)

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

Me sale (como esperaba)

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

Ahora, quiero confiar en este certificado yo mismo (imagine un certificado autoemitido donde pueda validar huella digital, etc.): ¿cómo puedo hacer una solicitud y validar / confiar en el certificado?

¡Probablemente necesito usar openssl para descargar el certificado, cargarlo en mi archivo y completar tls.Configstruct!?

Nota de seguridad: deshabilitar los controles de seguridad es peligroso y debe evitarse

Puede deshabilitar las comprobaciones de seguridad de forma global para todas las solicitudes del cliente predeterminado:

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)
    }
}

Puede deshabilitar la comprobación de seguridad para un cliente:

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)
    }
}

Aquí hay una manera de hacerlo sin perder la configuración predeterminada del DefaultTransport, y sin necesidad de la solicitud falsa según el comentario del usuario.

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},
}

ACTUALIZAR

Camino más corto:

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

Forma correcta (a partir de Go 1.13) (proporcionada por la respuesta a continuación ):

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

Advertencia : solo con fines de prueba / desarrollo. ¡Cualquier otra cosa, proceda bajo su propio riesgo!

¡Todas estas respuestas están equivocadas! No lo use InsecureSkipVerifypara tratar con un CN que no coincide con el nombre de host. Los desarrolladores de Go imprudentemente se mostraron inflexibles al no deshabilitar las comprobaciones de nombres de host (que tiene usos legítimos: túneles, nats, certificados de clúster compartidos, etc.), al tiempo que también tenían algo que se parecía, pero en realidad ignora por completo la comprobación de certificados. Debe saber que el certificado es válido y está firmado por un certificado en el que confía. Pero en escenarios comunes, sabe que el CN ​​no coincidirá con el nombre de host con el que se conectó. Para aquellos, establecido ServerNameen tls.Config. Si tls.Config.ServerName== remoteServerCN, entonces la verificación del certificado tendrá éxito. Esto es lo que quieres. InsecureSkipVerifysignifica que NO hay autenticación; y está maduro para un hombre en el medio; derrotando el propósito de usar TLS.

Hay un uso legítimo para InsecureSkipVerify: usarlo para conectarse a un host y tomar su certificado, luego desconectarlo inmediatamente. Si configura su código para usarlo InsecureSkipVerify, generalmente es porque no lo configuró ServerNamecorrectamente (tendrá que provenir de una variable ambiental o algo así; no se preocupe por este requisito ... hágalo correctamente).

En particular, si usa certificados de cliente y confía en ellos para la autenticación, básicamente tiene un inicio de sesión falso que en realidad ya no inicia sesión. ¡Rechace el código que sí lo hace InsecureSkipVerify, o aprenderá lo que está mal con él de la manera difícil!

La forma correcta de hacer esto si desea mantener la configuración de transporte predeterminada es ahora (a partir de Go 1.13):

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

Transport.Clone hace una copia profunda del transporte. De esta manera, no tiene que preocuparse por perder ningún campo nuevo que se agregue a la Transportestructura con el tiempo.

Si desea utilizar la configuración predeterminada del paquete http, por lo que no necesita crear un nuevo objeto de transporte y cliente, puede cambiar para ignorar la verificación del certificado de esta manera:

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

En general, el dominio DNS de la URL DEBE coincidir con el sujeto del certificado del certificado.

En el pasado, esto podría ser configurando el dominio como cn del certificado o estableciendo el dominio como un Nombre alternativo del sujeto.

El soporte para cn fue obsoleto durante mucho tiempo (desde 2000 en RFC 2818 ) y el navegador Chrome ya ni siquiera mirará el cn, por lo que hoy debe tener el dominio DNS de la URL como un nombre alternativo del sujeto.

RFC 6125 que prohíbe verificar el cn si existe SAN para Dominio DNS, pero no si SAN para Dirección IP está presente. El RFC 6125 también repite que cn está en desuso, lo que ya se dijo en el RFC 2818. Y el Foro del Navegador de la Autoridad de Certificación estará presente, lo que en combinación con el RFC 6125 esencialmente significa que cn nunca se comprobará el nombre de Dominio DNS.