Https e caddy

[Giuliano Curti]

Ciao a tutti,

faccio qualche domanda a proposito di HTTPS per un servizio (amatoriale) esposto al pubblico, spero di non scocciare (ogni tanto ritorno con questi dubbi..... :-)

1) intanto volevo sapere le impressioni/consigli se qualcuno qui usa caddy

2) mi affascina (da profano di reti, certificazioni, ecc.) l'apparente semplicità di caddy nel richiedere ed ottenere i certificati, ma ho anche timore di molti errori iniziali e quindi di venire bannato da Let's Encrypt;

c'è qualche modalità provvisoria per l'evenienza o meglio secondo voi affidarsi a certbot (che ha, mi sembra, una configurazione di prova)?(*)

3) in futuro potrei avere esigenza di gestire piu servizi dallo stesso indirizzo; la certificazione base mi sembra sia per un solo dominio; pensavo quindi di gestire i vari servizi come pagine del dominio principale e dovrei configurare caddy(/nginx/apache) in reverse proxy per l'occorrenza.

Qualcuno mi sa suggerire qualche lettura/esempio per passare dalla teoria ai fatti?

Questo cmq per il futuro, adesso andiamo pure un passo alla volta :-))

Grazie, un affettuoso e riconoscente saluto,

Giuliano

-

(*) questa soluzione avrebbe anche il vantaggio, se non ho equivocato le frastornate letture che ho fatto, di poter essere avviata da una macchina diversa e poi trasferire i certificati ottenuti sul server, soluzione che mi darebbe tutto il tempo di fare esperimenti senza dover fermare il servizio (che cmq non è critico).

[Giuliano Curti]

Qui mi rispondo da solo:

2) .......

c'è qualche modalità provvisoria per l'evenienza .........

Appena visto su indomus.it/Installare e configurare Caddy......:

{

  acme_ca https://acme-staging-v02.api.letsencrypt.org/directory

}

.....

[Paride Desimone]

Il 3 novembre 2023 10:30:30 UTC, Giuliano Curti <giuli...@gmail.com> ha scritto:

>3) in futuro potrei avere esigenza di gestire piu servizi dallo stesso
>indirizzo; la certificazione base mi sembra sia per un solo dominio;
>pensavo quindi di gestire i vari servizi come pagine del dominio principale
>e dovrei configurare caddy(/nginx/apache) in reverse proxy per l'occorrenza.

Per un solo dominio di 2 livello. Ciò significa che puoi avere anche un certificato wildcard che te lo gestisca, quindi infiniti domini di terzo livello.

/paride


--
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

[Giuliano Curti]

Il sab 4 nov 2023, 07:57 Paride Desimone <nos...@inventati.org> ha scritto:

Ciao Paride,

grazie del commento che mi consente di capire meglio il problema dei livelli

Il 3 novembre 2023 10:30:30 UTC, Giuliano Curti <giuli...@gmail.com> ha scritto:

>3) in futuro potrei avere esigenza di gestire piu servizi dallo stesso

>indirizzo; la certificazione base sembra sia per un solo dominio;
......

Per un solo dominio di 2 livello. Ciò significa che puoi avere anche un certificato wildcard che te lo gestisca, quindi infiniti domini di terzo livello.

i miei domini derivano da no-ip, del tipo xxxxx.ddns.net, pensavo fossero di terzo livello, sto sbagliando?

Nel caso come incide sul problema certificati?

/paride

Grazie, ciao,

Giuliano

[Davide Prina]

Giuliano Curti ha scritto:

> dovrei configurare caddy(/nginx/apache) in reverse proxy per l'occorrenza.

per Apache web server: oltre a guardare sul sito di Apache stesso ti
consiglio di dare un'occhiata anche al wiki di Debian, dove trovi spiegato
come poterlo configurare su Debian:

https://wiki.debian.org/FrontPage?action=fullsearch&context=180&value=apache&titlesearch=Titles

Per gestire più siti ti crei più file di configurazione .conf

Per il reverse proxy devi abilitare i moduli proxy e mox_proxy e guarda le
opzioni nel file di configurazione (il primo è per il flusso dall'esterno
all'interno, il secondo è per il viceversa):
ProxyPass
ProxyPassReverse

I comandi che devi conoscere sono:
a2dismod
a2enmod
a2ensite
a2dissite
a2enconf
a2disconf
apache2ctl configtest
systemctl restart apache2

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL
license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

[Giuliano Curti]

Il dom 5 nov 2023, 10:52 Davide Prina <Davide...@null.net> ha scritto:

Ciao Davide, grazie del riscontro

Giuliano Curti ha scritto:

> dovrei configurare caddy(/nginx/apache) in reverse proxy per l'occorrenza.

per Apache web server: oltre a guardare sul sito di Apache stesso ti

consiglio di dare un'occhiata anche al wiki di Debian, .....

Capisco bene che il tuo consiglio è di andare su apache tralasciando gli altri due (di nginx ne parlano un gran bene)? Mi guarderò la documentazione che mi hai indicato.

Per le certificazioni dovrei usare certbot, giusto?

Per gestire più siti ti crei più file di configurazione .conf

........

Qui approfitto per capirne di più.

Io riesco da profano a vedere 3 scenari (puramente immaginari, tanto per cercare di capire la logica):

1) gestire i servizi come pagine dello stesso dominio, quindi il server risponde a N chiamate tipo "mio_dominio ddns.net/servizio_X" offrendo a seconda del caso la risposta corretta; in tal caso potrei anche fare a meno del reverse proxy e me la caverei con 1 solo certificato; con un costo però, la maggior complessità del server;

2) più servizi sulla macchina gestiti da server diversi, esportati tramite un reverse proxy che passa la chiamata "mio_dominio ddns.net/servizio_X" al server X; ancora 1 solo certificato e server interni più snelli; necessità di configurare, come mi spiegavi e mi studierò, il reverse proxy;

3) mi chiedevo se era possibile una terza possibilità: N domini gestiti da N server esportati tramite un reverse proxy; in tal caso avrò bisogno di N certificati, ma mi viene il dubbio di cosa succeda al DNS, N domini che hanno tutti lo stesso indirizzo! Si può fare? E poi il reverse proxy sarebbe in grado di gestire in contemporanea chiamate a domini diversi?

4) mi sfugge qualche altra possibilità?

È un discorso ancora teorico, cmq N è dell'ordine 2, massimo 3; prima però mi devo occupare della certificazione di un dominio; il caso di servizi/domini multipli rimane congelato.

Ciao
Davide

Grazie infinite, ciao,

Giuliano

[Giuliano Curti]

Il dom 5 nov 2023, 19:55 Leonardo Boselli

Ciao Leonardo, grazie;

 <leo...@trail.it> ha scritto:

On Sun, 5 Nov 2023, Giuliano Curti wrote:
> 3) mi chiedevo se era possibile una terza possibilità: N domini gestiti da N
> server esportati tramite un reverse proxy; in tal caso avrò bisogno di N
> certificati, ma mi viene il dubbio di cosa succeda al DNS, N domini che
> hanno tutti lo stesso indirizzo! Si può fare? E poi il reverse proxy sarebbe
> in grado di gestire in contemporanea chiamate a domini diversi?

Un certificato può essere emesso per più di un dominio......

Colpa mia non averlo specificato, mi riferivo a certificati gratuiti che dovrebbero essere solo di tipo DV.

Ho appena visto però nelle FAQ del sito di Let's Encrypt che esiste il meccanismo SAN (Subject Alternative Name); me lo guarderò meglio.

e si riferisce a l
nome di dominio, non all'indirizzo della macchina.

Questo dovrebbe confermare che è possibile ottenerlo su una macchina diversa e poi trasferirlo (togliendo l'angoscia di operare sulla macchina di produzione (si fa per dire) :-)))

Leonardo Boselli

Grazie infinite, ciao,

Giuliano

[Leonardo Boselli]

On Sun, 5 Nov 2023, Giuliano Curti wrote:

> 3) mi chiedevo se era possibile una terza possibilità: N domini gestiti da N
> server esportati tramite un reverse proxy; in tal caso avrò bisogno di N
> certificati, ma mi viene il dubbio di cosa succeda al DNS, N domini che
> hanno tutti lo stesso indirizzo! Si può fare? E poi il reverse proxy sarebbe
> in grado di gestire in contemporanea chiamate a domini diversi?

Un certificato può essere emesso per più di un dominio. e si riferisce a l

nome di dominio, non all'indirizzo della macchina.

--
Leonardo Boselli
Firenze, Toscana, Europa
http://i.trail.it
tel:+393287329225

[Leonardo Boselli]

On Sun, 5 Nov 2023, Giuliano Curti wrote:
> Questo dovrebbe confermare che è possibile ottenerlo su una macchina diversa
> e poi trasferirlo (togliendo l'angoscia di operare sulla macchina di
> produzione (si fa per dire) :-)))

si fa per dire ... perché per ottenere il certificato gratuito la
autenticazione viene fatta chiedendo a certbot o simili di scrivere nel
server un certo file, che se trovato conferma che chi richiede il
certificato è il detentore del nome.
quindi durante la certificazione e i rinnovi successivi il dominio deve
puntare alla macchina che ha certbot.
Il traferimento del certificato di fatto serve se devi spostare il server
da una macchina all'altra e quindi hai subito un certificato valido.

[Davide Prina]

Leonardo Boselli ha scritto:

> Un certificato può essere emesso per più di un dominio. e si riferisce a l
> nome di dominio,

in alternativa si possono creare più siti sotto lo stesso dominio, usando
sotto-domini o percorsi differenti.

> non all'indirizzo della macchina.

questo non è corretto, io ho visto certificati emessi per un indirizzo IP.
Li ho visti per siti interni ad una rete 10.x.x.x e quindi penso che in
teoria possano essere emessi anche per altri indirizzi.
L'unica cosa è che se lo fai emettere per un indirizzo IP poi non puoi
cambiarlo, pena il non funzionamento dell'esposizione in TLS.

[Davide Prina]

Giuliano Curti ha scritto:

> Davide Prin ha scritto:

 

>> Giuliano Curti ha scritto:

>>> dovrei configurare caddy(/nginx/apache) in reverse proxy per
>>> l'occorrenza.

>> per Apache web server:

> Capisco bene che il tuo consiglio è di andare su apache tralasciando
> gli altri due (di nginx ne parlano un gran bene)?

io mi ricordo che avevo guardato poco tempo fa (forse circa 2 anni fa)
e le prestazioni sui equivalevano tra Apache e Nginx e, se non ricordo
male, erano i più prestazionali... naturalmente in casi generici.
Un bel po' di anni fa Nginx aveva prestazioni migliori e gli è rimasto
questo "vanto", anche se, da quel che ho capito, ora non è più vero.

Nginx non l'ho mai usato, ma se non ricordo male è stato progettato
per servire codice statico, ed è qui che offre il suo meglio, mentre
Apache web server è ottimale anche con codice dinamico.

> potrei anche fare a meno del reverse proxy

il reverse proxy può essere usato per diversi scopi.
Principalmente traduce "indirizzi/percorsi" del chiamante in
"indirizzi/percorsi" locali.
Di solito è usato per creare una suddivisione fisica tra la parte
front-end del tuo applicativo con quella back-end.
Ma puoi usarlo anche per ridirigere verso la macchina che offre
effettivamente il servizio di esposizione di uno dei domini che
gestisci.

Poi ci sono molti altri parametri che io non ho mai visto e che
permetteranno di ottenere altri risultati a cui non ho neanche
pensato.

[Giuliano Curti]

Il dom 12 nov 2023, 10:46 Davide Prina <Davide...@null.net> ha scritto:

Ciao Davide,

grazie del riscontro;

......

> Capisco bene che il tuo consiglio è di andare su apache tralasciando
> gli altri due (di nginx ne parlano un gran bene)?

io mi ricordo che avevo guardato poco tempo fa (forse circa 2 anni fa)
e le prestazioni sui equivalevano tra Apache e Nginx e, se non ricordo

male, erano i più prestazionali... ....

Qui ti stoppo subito :-) il mio problema non sono le prestazioni, ma mettere in piedi un servizio che funzioni e possibilmente provvisto di certificato; delle prestazioni mi occuperò in seguito.

Ho pensato di partire con Caddy perché mi stuzzica l'apparente facilità di creazione e rinnovo dei certificati; cercherò di capire se la facilità è concreta o, appunto, solo apparente (dovrò anche capire come gestire sotto caddy qgis-server in fastcgi, tutte le guide contemplano apache e nginx).

È vero ci sarebbe l'alternativa certbot che mi lascerebbe più elasticità nella scelta del web server, ma purtroppo sul sito consigliano una versione snap; per quanto dispongo di una macchina Ubuntu, è un formato di cui mi vorrei liberare, quindi la scelta quasi obbligata diventa caddy.

Quindi la mia roadmsp è tracciata:

1) installazione caddy su testing: fatto

2) pagina statica di prova: fatto

3) reverse proxy di wsgi

4) reverse proxy di fastcgi per qgis-server

5) certificati di prova

6) certificati finali.

Troverò sicuramente occasione per rompere ancora :-) :-)

.....

Ciao
Davide

Grazie della pazienza, saluti,

Giuliano

PS: ho appena visto l'amico Luca scusarsi per scrivere da Gmail per Android; anch'io scrivo da lì e non ho mai pensato a come arrivano le mie mail; chiedo scusa se la negligenza ha creato disturbo; datemi per cortesia indicazioni sui settaggi per riportare nel caso la cosa in limiti tollerabili.

[Leonardo Boselli]

chiedo una cosa: questi certificati per indirizzi interni erano esessi per
un indirizzo numerico o per un nome, che poi veniva risolto con un
indirizzo locale ?
Perché nulla osta di ottenere il certificato ponendo nel DNS un indirizzo
pubblico a cui risponde la macchina che si autentica; dopo di che mettere
nel DNS un indirizzo privato, che quindi sarà accessibile solo dalle
macchine della intranet.
dare un certificato a 10.10.10.10 non è ammesso, ma dare un certificato a
serveri.my-nonpublic-network-example.net che ha un record A 10.10.10.10 è
perfettamante ammissibile. ( e il record A lo puoi semp0re cambiare: pensa
a quei domini che hanno solo un cname: quello che succede ai record A e
AAAA della macchina a cui punta il cname sogno al di fuori del controllo.


On Mon, 13 Nov 2023, Diego Zuccato wrote:
> Se li hai visti emessi da CA riconosciute per indirizzi di reti non
> routabili, allora vanno segnalati: sono contrari alle policy CA/B forum!
>
> Infatti il certificato potrebbe venir riutilizzato su una rete diversa,
> facendo così credere all'utente di essere collegato ad un sito quando invece
> è collegato ad un altro.
> Inoltre, non essendo indirizzi routabili, vuol dire che non c'è stata
> verifica del sito.

>> questo non è corretto, io ho visto certificati emessi per un indirizzo IP.
>> Li ho visti per siti interni ad una rete 10.x.x.x e quindi penso che in
>> teoria possano essere emessi anche per altri indirizzi.
>> L'unica cosa è che se lo fai emettere per un indirizzo IP poi non puoi
>> cambiarlo, pena il non funzionamento dell'esposizione in TLS.

[Davide Prina]

Leonardo Boselli ha scritto:

> dare un certificato a 10.10.10.10 non è ammesso, ma dare un certificato a
> serveri.my-nonpublic-network-example.net che ha un record A 10.10.10.10 è
> perfettamante ammissibile. ( e il record A lo puoi semp0re cambiare: pensa
> a quei domini che hanno solo un cname: quello che succede ai record A e
> AAAA della macchina a cui punta il cname sogno al di fuori del controllo.

a me sembra di ricordare che, per il caso che avevo visto, il certificato
fosse stato emesso su un IP fisso (stavo aiutando a capire il problema di
non "funzionamento" di un sito interno e il problema era che il certificato
non veniva riconosciuto valido perché emesso per qualcosa di diverso da
quello su cui era esposto).
Poi non so se per errore avessero creato il certificato sull'IP al posto
che sul name...

Non sono un esperto di certificati, ma penso che in ogni caso che per gli
indirizzi ip/nomi di rete interna non si possa avere un certificato di una
CA riconosciuta, ma si possa solo usare una CA interna all'organizzazione.

Se qualcuno prende quel certificato e lo usa in un'altra rete interna non
mi sembra che ci siano problemi di sicurezza, poiché se non riconosci già
quella CA come trusted (cosa che dovrebbe essere impossibile) ti viene
indicato che è firmato da una CA non riconosciuta... e quindi o blocchi
la navigazione o fai considerare affidabile il certificato
(temporaneamente o in modo indefinito).