Let's Encrypt per siti Web intranet?

Let's Encrypt può emettere solo certificati per nomi DNS validi. Quindi se la tua intranet utilizza un nome di dominio inventato come intranet.mycompany.local , allora non funzionerà.

Se hai un vero nome DNS come intranet.mycompany.com (anche se non si risolve esternamente alla tua intranet), puoi usare Let's Encrypt per emettere certificati per esso. Se il dominio fa risolve esternamente un server che può rispondere sulla porta 80 (che non deve essere effettivamente parte della tua intranet, se hai DNS split-horizon ), è possibile utilizzare http-01 sfida.

In alternativa, puoi utilizzare dns-01 challenge (completamente supportato in Certbot 0.10.0 e più tardi, così come altri client come disidratati , getssl e acme.sh ). Poiché questa sfida funziona eseguendo il provisioning dei record TXT DNS, non è mai necessario puntare un record A su un indirizzo IP pubblico.

Quindi la tua intranet non ha bisogno di essere raggiungibile da Internet, ma il tuo nome di dominio deve esistere nel DNS pubblico sotto il tuo controllo.

Let's Encrypt invia tutti i certificati emessi ai registri di trasparenza dei certificati pubblici. Se consideri privato il tuo dominio intranet (sotto), potresti essere preoccupato di questo, ma nota che altro Le CA probabilmente dovranno fare qualcosa di simile presto e la sicurezza della tua intranet non dovrebbe dipendere dal mantenere il suo nome di dominio segreto in ogni caso.

Se stai cercando un servizio interno alla CA per una Intranet, una CA pubblica come Lets Encrypt potrebbe non funzionare, poiché vorrebbe riconnettersi ai suoi server per gestire la richiesta e la firma del cert. Questo presuppone che tu non abbia accesso a Internet dal tuo server web intranet; è necessario installare un client sul server web affinché possa comunicare con il servizio Lets Encrypt.

How can they generate a CERT for their HTTPS website using Let's Encrypt?

LE ha un cliente dedicato per questo scopo. Vedi come funziona

Does the LTS webbrowsers have the Let's Encrypt as CA?

C'è un supporto limitato per i certificati di root CA pronti per il browser; vedi link . Hanno certificati pubblici sul sito al link

Torniamo al punto principale, ovvero l'emissione di certificati SSL accettati dal browser che non generano avvisi. Come suggerisce RoraZ, è necessario che gli utenti importino il certificato autofirmato dell'azienda per eliminare gli avvisi ricorrenti del browser e impedire agli utenti di sviluppare abitudine semplicemente accettando certificati non validi.

Usiamo OpenSSL per permetterci di funzionare come nostra autorità di certificazione, generando una CA radice che tutti gli utenti devono importare, consentendoci così di generare eventuali certificati aggiuntivi che verranno automaticamente accettati dal browser di tutti i dipendenti, o qualsiasi servizio che si basa su SSL. Questo è diverso rispetto all'importazione semplice del certificato autofirmato secondo necessità; stai effettivamente creando un certificato CA root e importandolo. In futuro, è possibile emettere qualsiasi numero di certificati per diversi nomi comuni, firmati da questa CA, e sono validi e affidabili tramite la propria autorità di certificazione radice privata.

Per creare e gestire la tua autorità di certificazione, vedi link

How can they generate a CERT for their HTTPS website using Let's Encrypt?

Assolutamente no. Questo è solo per i siti pubblici raggiungibili .

( Aggiornamento 2016-04-22: Forse "per niente" è un po 'troppo difficile. Ecco un piccolo dettaglio: LE è su misura per i siti pubblici raggiungibili Hai bisogno di un server che risponda al nome DNS quando LE chiede. Ora se hai configurato il tuo server DNS per dare risposte diverse a seconda di chi sta effettivamente ponendo la domanda - qualcuno dall'interno o dall'esterno aka Split-Brain -DNS - quindi puoi reindirizzare la richiesta di verifica a qualsiasi host che desideri.-Ma questo non è un caso d'uso con cui LE ti aiuta davvero. Al contrario: nel 2015 c'era questa esplicita intenzione: "abbiamo in programma di cambiare frequentemente il set di IP da cui viene convalidato " . - In questo modo è praticamente impossibile per la whitelist degli IP per gli host di convalida LE sul firewall perché questi IP possono cambiare frequentemente.

Does the LTS webbrowsers have the Let's Encrypt as CA?

Sì. La loro CA è firmata da una CA ben nota e ben consolidata. (Ovvero da IdenTrust .) Quindi tutti i client che si fidano di quella vecchia CA si fidano anche della nuova Let's-Encrypt CA subito.

Per una soluzione adeguata è possibile eseguire una propria istanza boulder , ovvero la parte del server di consentire la crittografia, sulla rete. Quindi puoi utilizzare tutti i client ufficiali e non ufficiali con il tuo ACME-Server se supportano l'utilizzo di diversi URL ACME (quelli ufficiali, per altri devi cercarli nella loro documentazione o nel codice sorgente).

Quindi devi importare il certificato CA nel trust store dei client usando i tuoi server.

Se hai solo pochi server che eseguono boulder e "permetti la tua crittografia" probabilmente non è la scelta migliore e puoi usare strumenti più semplici come easy rsa .

Se possiedi i domini reali e non ne vuoi uno per domini come localhost o IP di rete interna, puoi generarne uno su Internet pubblico, puntare a un sistema vuoto, quindi trasferirlo alla tua intranet usando rsync o simile.

Ora puoi anche apparentemente ottenere un carattere jolly, quindi *.internal.yoursite.extension potrebbe funzionare. Ovviamente è inutile per spoofing di siti come microsoft.com.

Posso capire perché spoofing dei siti non è auspicabile, ma posso anche vedere come può essere utile non dover installare CA su ogni workstation nell'organizzazione.