Come devono essere condivisi i certificati tra un proxy e un frontend?

Question

Come devono essere condivisi i certificati tra un proxy e un frontend?

#1 da (2 voti)

6

Al lavoro, mi è stato chiesto di esaminare la creazione di una topologia di riferimento per un'applicazione di chat WebSocket, che include un proxy tra il server front-end e il back-end. Al momento, sto ancora eseguendo il frontend e il backend sullo stesso server per lo sviluppo, ma ho temporaneamente impostato i WebSockets affinché facciano riferimento al proxy, che si trova su un server completamente separato in laboratorio. Entrambi i server si trovano su una rete interna e ciascuno ha un certificato autofirmato separato.

Quando stavo testando il WebSocket su TLS, non è riuscito a causa dell'autocertificazione del certificato (senza mostrare alcun dialogo per fare un'eccezione) finché non mi sono collegato direttamente al proxy e ho fatto un'eccezione per il certificato. Dopo di ciò, ha funzionato perfettamente, ma in pratica il visitatore probabilmente non sarebbe stato autorizzato a farlo. Quindi, ho bisogno di scoprire come certificare entrambi allo stesso tempo.

Per quanto ne so, i modi principali per farlo sono:

Inserisci il proxy e il frontend su diversi sottodomini (ad es. frontend.domain.com e proxy.domain.com ) e utilizza un certificato jolly per il sito. In laboratorio sarebbe più semplice e veloce lavorare in laboratorio, ma l'IETF scoraggia questo .
Utilizzare un singolo certificato con i nomi alternativi oggetto e includere frontend.mydomain.com e proxy.mydomain.com nel campo SAN per www. mydomain.com . Per quanto posso dire, questo condivide il problema di garantire i domini canaglia / buggy.
Utilizza certs completamente separati per i due server, come sto già facendo. È più complicato lavorare con, specialmente con i certificati autofirmati, ma se un dominio è compromesso, questo è solo un punto di errore. La mia domanda principale qui è che se il proxy e i certificati di frontend non fossero autofirmati, sarebbe più probabile che funzionasse?

C'è qualcosa che mi è mancato con quanto sopra, o ci sono altri metodi?

EDIT 22/07/2015: Per inciso, mentre inviavo una XMLHttpRequest tramite lo stesso meccanismo, ho scoperto che dovevo disattivare la verifica della cert tra il proxy e il back-end per consentire all'handshake SSL di andare avanti, quindi Mi chiedo se i miei certificati autofirmati fossero la vera causa del problema. Tuttavia, probabilmente questo non risolve il mio problema sopra.

proxy tls certificates

posta Philip Rowlands 21.07.2015 - 13:25

fonte

1 risposta

Leggi altre domande sui tag proxy tls certificates

Come prevenire l'abuso di SMTP inviando e-mail di spam? Malware: estrai le chiavi private dalla smartcard?

score 2 · Accepted Answer

Se possiedi un certificato autofirmato, devi affidarti ai tuoi clienti.

In alternativa puoi fare in modo che il client non verifichi se il certificato è attendibile, ma è una pessima idea.

Il modo in cui lo fai dipende dai tuoi clienti. Se hai qualcosa di simile:

[user-agent]---------[frontend]---------[proxy]---------[backend]

L'user-agent (probabilmente un browser) è il client per frontend, frontend è il client per proxy e proxy è il client per back-end.

Ogni client qui deve fidarsi del certificato offerto dal server, sia perché è firmato da un'entità già affidabile, sia perché si aggiunge il certificato autofirmato al truststore.

Quindi sì, l'autofirmato può darti problemi

Se il proxy esiste per motivi di scalabilità, in futuro ci saranno più host di back-end.

Se tutte le comunicazioni dietro al frontend sono interne alla tua organizzazione, puoi configurare la tua CA interna e fidarti del suo certificato di root nel frontend e nel proxy.

In questo modo è possibile aggiungere internamente nuovi host ciascuno con il proprio certificato e i client lo considereranno automaticamente.

L'utilizzo di certificati diversi per server diversi è generalmente una buona idea, indipendentemente dal fatto che si distribuisca o meno la propria CA. Quando una chiave è compromessa, è necessario revocare i certificati per quella chiave e qualsiasi host che condivide i certificati con quello compromesso richiederà anche nuovi certificati.