Tuve que abrirme camino a través de certificados autofirmados en Windows combinando partes de las respuestas dadas y más recursos. Aquí está mi propio (y con suerte completo) recorrido. Espero que te ahorre algo de mi propia curva de aprendizaje dolorosa. También contiene información sobre temas relacionados que aparecerán tarde o temprano cuando cree sus propios certificados.
Cree un certificado autofirmado en Windows 10 y versiones inferiores
No use makecert.exe. Ha sido desaprobado por Microsoft.
La forma moderna utiliza un comando Powershell.
Windows 10
Abra Powershell con privilegios de administrador:
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My -FriendlyName "Dev Cert *.dev.local, dev.local, localhost" -NotAfter (Get-Date).AddYears(15)
Windows 8, Windows Server 2012 R2:
En Powershell en estos sistemas, los parámetros -FriendlyName y -NotAfter no existen. Simplemente quítelos de la línea de comando anterior.
Abra Powershell con privilegios de administrador:
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My
Una alternativa es utilizar el método para la versión anterior de Windows a continuación, que le permite utilizar todas las características de Win 10 para la creación de certificados ...
Versiones anteriores de Windows:
Mi recomendación para versiones anteriores de Windows es crear el certificado en una máquina Win 10, exportarlo a un archivo .PFX usando una instancia de mmc (consulte "Confiar en el certificado" a continuación) e importarlo en el almacén de certificados en la máquina de destino con el antiguo sistema operativo Windows. Para importar el certificado NO haga clic derecho sobre él. Aunque hay un elemento de "Importar certificado" en el menú contextual, falló en todas mis pruebas para usarlo en Win Server 2008. En su lugar, abra otra instancia de mmc en la máquina de destino, vaya a "Certificados (equipo local) / Personal / Certificados" , haga clic derecho en el panel central y seleccione Todas las tareas → Importar.
El certificado resultante
Los dos comandos anteriores crean un certificado para los dominios localhost
y *.dev.local
.
La versión Win10 también tiene una duración de 15 años y un nombre para mostrar legible de "Dev Cert * .dev.local, dev.local, localhost".
Actualización: si proporciona varias entradas de nombre de host en el parámetro -DnsName
(como se muestra arriba), la primera de estas entradas se convertirá en el Asunto del dominio (Nombre común AKA). La lista completa de todas las entradas de nombre de host se almacenará en el campo Nombre alternativo del sujeto (SAN) del certificado. (Gracias a @BenSewards por señalar eso).
Después de la creación, el certificado estará disponible de inmediato en cualquier enlace HTTPS de IIS (instrucciones a continuación).
Confía en el certificado
El nuevo certificado no forma parte de ninguna cadena de confianza y, por lo tanto, no se considera confiable por ningún navegador. Para cambiar eso, copiaremos el certificado al almacén de certificados para las CA raíz confiables en su máquina:
Abra mmc.exe, Archivo → Agregar o quitar complemento → elija "Certificados" en la columna izquierda → Agregar → elija "Cuenta de equipo" → Siguiente → "Equipo local ..." → Finalizar → Aceptar
En la columna izquierda, seleccione "Certificados (equipo local) / Personal / Certificados".
Encuentre el certificado recién creado (en Win 10 la columna "Nombre descriptivo" puede ayudar).
Seleccione este certificado y presione Ctrl-C para copiarlo al portapapeles.
En la columna de la izquierda, seleccione "Certificados (equipo local) / CA raíz / certificados de confianza".
Presione Ctrl-V para pegar su certificado en esta tienda.
El certificado debe aparecer en la lista de Autoridades raíz de confianza y ahora se considera confiable.
Uso en IIS
Ahora puede ir al Administrador de IIS, seleccionar los enlaces de un sitio web local → Agregar → https → ingrese un nombre de host del formulario myname.dev.local
(su *.dev.local
certificado solo es válido para ) y seleccione el nuevo certificado → Aceptar.
Agregar a hosts
Agregue también su nombre de host a C: \ Windows \ System32 \ drivers \ etc \ hosts:
127.0.0.1 myname.dev.local
Contento
Ahora Chrome e IE deberían tratar el certificado como confiable y cargar su sitio web cuando se abra https://myname.dev.local
.
Firefox mantiene su propio almacén de certificados. Para agregar su certificado aquí, debe abrir su sitio web en FF y agregarlo a las excepciones cuando FF le advierte sobre el certificado.
Para el navegador Edge puede que se necesite más acción (ver más abajo).
Prueba el certificado
Para probar sus certificados, Firefox es su mejor opción. (Créeme, yo también soy un fanático de Chrome, pero FF es mejor en este caso).
Aquí están las razones:
- Firefox usa su propio caché SSL, que se purga en shift-reload. Por lo tanto, cualquier cambio en los certificados de sus sitios web locales se reflejará inmediatamente en las advertencias de FF, mientras que otros navegadores pueden necesitar un reinicio o una purga manual del caché SSL de Windows.
- Además, FF le brinda algunos consejos valiosos para verificar la validez de su certificado: Haga clic en Avanzado cuando FF muestre su advertencia de certificado. FF le mostrará un bloque de texto corto con una o más advertencias posibles en las líneas centrales del bloque de texto:
El certificado no es confiable porque está autofirmado.
¡Esta advertencia es correcta! Como se señaló anteriormente, Firefox no utiliza el almacén de certificados de Windows y solo confiará en este certificado si agrega una excepción. El botón para hacer esto está justo debajo de las advertencias.
El certificado no es válido para el nombre ...
Esta advertencia muestra que hiciste algo mal. El dominio (comodín) de su certificado no coincide con el dominio de su sitio web. El problema debe resolverse cambiando el (sub) dominio de su sitio web o emitiendo un nuevo certificado que coincida. De hecho, podría agregar una excepción en FF incluso si el certificado no coincide, pero nunca obtendría un símbolo de candado verde en Chrome con tal combinación.
Firefox puede mostrar muchas otras advertencias de certificados agradables y comprensibles en este lugar, como certificados vencidos, certificados con algoritmos de firma obsoletos, etc. No encontré ningún otro navegador que me diera ese nivel de comentarios para resolver cualquier problema.
¿Qué patrón de (sub) dominio debería elegir desarrollar?
En el comando New-SelfSignedCertificate anterior, utilizamos el dominio comodín *.dev.local
.
Puedes pensar: ¿Por qué no usar *.local
?
Razón simple: es ilegal como dominio comodín.
Los certificados comodín deben contener al menos un nombre de dominio de segundo nivel.
Por lo tanto, los dominios del formulario *.local
son buenos para desarrollar sitios web HTTP. Pero no tanto para HTTPS, porque se vería obligado a emitir un nuevo certificado coincidente para cada nuevo proyecto que inicie.
Notas secundarias importantes:
- Los dominios de host válidos SOLO pueden contener letras a través de z, dígitos, guiones y puntos. ¡No se permiten guiones bajos! Algunos navegadores son muy exigentes con este detalle y pueden causarle dificultades cuando se niegan obstinadamente a hacer coincidir su dominio
motör_head.dev.local
con su patrón comodín *.dev.local
. Cumplirán cuando cambies a motoer-head.dev.local
.
- Un comodín en un certificado solo coincidirá con UNA etiqueta (= sección entre dos puntos) en un dominio, nunca más.
*.dev.local
coincide myname.dev.local
pero NO other.myname.dev.local
!
- Los comodines multinivel (
*.*.dev.local
) NO son posibles en los certificados. Por other.myname.dev.local
lo tanto , solo se puede cubrir con un comodín del formulario *.myname.dev.local
. Como resultado, es mejor no usar una parte de dominio de cuarto nivel. Pon todas tus variaciones en la parte del tercer nivel. De esta manera, se llevará bien con un solo certificado para todos sus sitios de desarrollo.
El problema con Edge
Esto no se trata realmente de certificados autofirmados, sino que está relacionado con todo el proceso:
después de seguir los pasos anteriores, Edge puede no mostrar ningún contenido al abrirlo myname.dev.local
.
La razón es una característica de la administración de red de Windows 10 para aplicaciones modernas, llamada "Aislamiento de red".
Para resolver ese problema, abra un símbolo del sistema con privilegios de administrador e ingrese el siguiente comando una vez:
CheckNetIsolation LoopbackExempt -a -n=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Puede encontrar más información sobre Edge y aislamiento de red aquí:
https://blogs.msdn.microsoft.com/msgulfcommunity/2015/07/01/how-to-debug-localhost-on-microsoft-edge/
makecert.exe
estar en mi camino. Para los certificados, pensé que sería más seguro y usaría-a SHA512 -len 8192
; me llevó una eternidad generarlos. Y como sospechaba que podría, no tuvo ningún impacto en el nivel de encriptación que usó IIS. Por defecto, IIS usa 128 bits, debe hacer cosas de política de grupo para cambiar esto. De otra nota para otros lectores: no cambies los números mágicos después-eku
, son obligatorios.