Apache HTTPD/mod_proxy/Tomcat e SSL con autorizzazione client

Question

Sono sicuro che questa è una FAQ ma non ho trovato nulla che ho riconosciuto come la stessa domanda.

Ho diverse app Web in esecuzione in Tomcat, con alcune pagine, ad es. la pagina di accesso protetta da SSL come definito dagli elementi di riservatezza nel loro web.xmls. Una delle app accetta anche l'autenticazione client tramite certificato. Ho anche uno schema di autenticazione dell'autorizzazione basata su JAAS piuttosto ampio &, e ci sono tutti i tipi di codice condiviso e diverse configurazioni JAAS ecc. Tra le varie applicazioni web.

Non voglio davvero disturbare nulla durante il completamento del seguente.

Sono ora in procinto di inserire Apache HTTPD con mod-proxy e mod-proxy-bilanciatore davanti a Tomcat come bilanciamento del carico, prima di aggiungere altre istanze di Tomcat.

Quello che voglio ottenere per le richieste HTTPS è che vengono reindirizzati "ciechi" a Tomcat senza che HTTPD sia l'endpoint SSL, ovvero HTTPD passa semplicemente ciphertext direttamente a Tomcat in modo che TC possa continuare a fare ciò che sta già facendo con gli accessi , SSL, garanzie di riservatezza web.xml e, soprattutto, autenticazione client.

Ciò è possibile con la configurazione che ho descritto?

Sono molto familiare con le applicazioni web e SSL, HTTPS e Tomcat, ma la mia conoscenza dei limiti di Apache HTTPD è limitata.

felice di avere questa spostato, se necessario, ma è una specie di programmazione con i file di configurazione;)

Answer 1

Questo suona simile a this question, dove ho risposto che non è possibile:

Puoi basta inoltrare il traffico SSL/TLS a Tomcat da Apache. O la tua connessione SSL termina con Apache, quindi dovresti invertire il proxy il traffico verso Tomcat (SSL [tra Httpd e Tomcat] è raramente utile in questo caso), oppure fai i client si connettono direttamente a Tomcat e lascia che gestisca la connessione SSL .

Ammetto che è un po 'a corto di collegamenti per sostenere questa affermazione. Credo che potrei sbagliarmi (non l'ho mai visto, ma questo non significa che non esista ...).

Come sapete, è necessario un collegamento diretto o una connessione interamente inoltrata tra l'utente-agente e l'endpoint SSL (in questo caso, si desidera che sia Tomcat). Ciò significa che Apache Httpd non sarà in grado di esaminare l'URL: conoscerà al meglio il nome host (quando si utilizza l'indicazione del nome del server).

L'unica opzione che non sembra dipendere da un URL nella mod_proxy documentation è AllowCONNECT, che è quello che viene utilizzato per avanti server proxy HTTPS.

Anche the options in mod_proxy_balancer prevede un percorso in corrispondenza di un punto della configurazione. La sua documentazione non menziona SSL/HTTPS ("Fornisce il supporto per il bilanciamento del carico per i protocolli HTTP, FTP e AJP13"), mentre mod_proxy parla almeno di SSL quando menziona CONNECT.

vorrei suggerire un paio di opzioni:

• Utilizzando un iptables based di bilanciamento del carico, senza passare attraverso Httpd, che termina le connessioni in Tomcat direttamente.

• Terminare la connessione SSL/TLS su Httpd e utilizzare un semplice proxy inverso HTTP per Tomcat.

Questa seconda opzione richiede un po 'più di configurazione per gestire i certificati client e i vincoli di sicurezza di Tomcat.

Se la tua webapp è stata configurata con <transport-guarantee>CONFIDENTIAL</transport-guarantee>, è necessario impostare Tomcat per contrassegnare le connessioni come sicure, nonostante vengano viste dalla normale porta HTTP. Per Tomcat 5, here is an article (originariamente in francese, ma le traduzioni automatiche non sono male) che descrive come implementare una valvola per impostare isSecure(). (Se non hai familiarità con valves, sono simili ai filtri, ma operano all'interno di Tomcat stesso, prima che la richiesta venga propagata alla webapp. Possono essere configurati all'interno di Catalina) Penso che da Tomcat 5.5, lo HTTP connector secure option faccia esattamente questo, senza richiedere la propria valvola. Anche il connettore AJP ha un'opzione simile (se si utilizza mod_proxy_ajp o mod_jk).

Se si utilizza il connettore AJP, mod_proxy_ajp inoltra il primo certificato nella catena e lo rende disponibile all'interno di Tomcat (tramite il normale attributo di richiesta). Probabilmente avrai bisogno di SSLOptions +ExportCertData +StdEnvVars. mod_jk (sebbene deprecato per quanto ne so) può anche inoltrare l'intera catena inviata dal client (usando JkOptions +ForwardSSLCertChain). Questo può essere necessario quando si utilizza proxy certificates (che sono prive di significato senza la catena fino al loro certificato di entità finale).

Se si desidera utilizzare mod_proxy_http, un trucco è passare il certificato tramite an HTTP header (mod_header), utilizzando qualcosa come RequestHeader set X-ClientCert %{SSL_CLIENT_CERT}s. Non riesco a ricordare i dettagli esatti, ma è importante assicurarsi che questa intestazione sia deselezionata in modo che non provenga mai dal browser del client (chi potrebbe falsificarlo altrimenti). Se ti serve la catena completa, puoi provare this Httpd patch attempt. Questo approccio richiede probabilmente un filtro/valvola supplementare per trasformare l'intestazione nello javax.servlet.request.X509Certificate (analizzando i blocchi PEM).

Un paio di altri punti che possono essere di interesse:

• Se ricordo bene, è necessario scaricare i file del CRL esplicitamente Httpd e configure it to use them. A seconda della versione di Httpd che stai utilizzando, potrebbe essere necessario restart it to reload the CRLs.
• Se si sta negoziando di nuovo per ottenere il certificato client, una direttiva CLIENT-CERT non renderà Httpd richiedere un certificato client per quanto ne so (altrimenti viene fatto tramite una valvola che può accedere allo SSLSession quando si utilizza il Connettore JSSE direttamente). Potrebbe essere necessario configurare il percorso corrispondente in Httpd per richiedere il certificato client.