Configurare correttamente un’infrastruttura di reverse proxy è essenziale per garantire sicurezza, scalabilità e semplicità di gestione nei moderni ambienti di rete.
Quando si utilizzano strumenti come Nginx Proxy Manager, l’uso di un certificato wildcard può semplificare enormemente la gestione dei domini e sottodomini, evitando la necessità di generare certificati singoli per ogni servizio.
In questo contesto, sfruttare la Certification Authority di Microsoft rappresenta una soluzione solida e integrata per chi opera in ambienti Windows o Active Directory.
In questo articolo vedremo passo dopo passo come generare un certificato wildcard tramite la CA di Microsoft e come integrarlo in Nginx Proxy Manager, garantendo così una configurazione pulita, sicura e centralizzata.
PREREQUISITI
Certification Authority di Microsoft Installata
Nginx Proxy Manager Installato
Installazione e Configurazione di Nginx Proxy Manager (NPM) su Ubuntu Server 24.04
GENERAZIONE DELLA CRS DAL SERVER NGINX PROXY MANAGER
Dal Server Nginx Proxy Manager o da un qualsiasi altro server Linux eseguire il comando:
|
0 |
openssl genrsa -out wildcard_test.lab.key 3072
|
Creare un file di configurazione per includere i SAN con il seguente comando:
|
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
cat > csr.conf <<'EOF'
[ req ]
default_md = sha256
prompt = no
encrypt_key = no
distinguished_name = dn
req_extensions = req_ext
[ dn ]
C = IT
ST = Piemonte
L = Torino
O = Casa-Raf
CN = *.mypsx.net
[ req_ext ]
subjectAltName = @alt_names
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
[ alt_names ]
DNS.1 = *.test.lab
DNS.2 = test.lab
EOF
|
Generare la CSR con il comando:
|
0 |
openssl req -new -key wildcard_test.lab.key -out wildcard_test.lab.csr -config csr.conf
|
All’interno della cartella verrà creato un file wildcard_test.lab.csr
Eseguire il comando:
|
0 |
cat wildcard_test.lab.csr
|
Dovremmo visualizzare un output simile al seguente:
|
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
-----BEGIN CERTIFICATE REQUEST-----
MIIC3DCCAcQCAQAwgYsxCzAJBgNVBAYTAklUMREwDwYDVQQIDAhNaWxhbm8xEjAQ
BgNVBAcMCU1pbGFubzo2MTERMA8GA1UECgwIQ29tcGFueTEUMBIGA1UEAwwLKi5t
eXBzeC5uZXQxHzAdBgkqhkiG9w0BCQEWEGFkbWluQG15cHN4Lm5ldDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+Viknr+2vlG0X8pCeP7xDhVZB5D8uQ
RnlYdrW2mlOFiG4oYzQZlfv/3Aw5lB6XGv3Sk9K0DYjUnbrQmp05U4J7DUlA2Aiv
Yo41Yd3ug2v4rU6gP6ebfENJjAzfrZBWZekKmHecOQ2uA9YgjvlzLb+yAB5ehkLn
QlE3qU5G4N8VjxA2Koy+g2lqXK1D8yO6bHrKhAMZ2FdYJynO4V6OQ6L/fZemGoCt
HL8ezcM5ErGiREr66VwHk4bE0MJBGpjUqLf5XYxT8QJPGk1RYr6GcWQzE9vdmCJS
X/PMRSRrGZ+MTeJxj3F1IQpKrqVzmbvnOc6u8jFxWRA4r0MtSzJ0leECAwEAAaA7
MDkGCSqGSIb3DQEJDjAcMBowGAYDVR0RBBEwD4INKi5teXBzeC5uZXQwDQYJKoZI
hvcNAQELBQADggEBAHgTS2u2NnULjzvlfwhFdn9LROpJmIsZqUkTavI6hw6HtA9q
N3sYvvDqxCZbqPOzRpCXFhGl4DglLkYB9Gx5Pg1gM7pI1u2UxxbPZcb0MZP8Hpm6
/xFHi+FZfUdKx9cb7ryQhQ4UHeNGmtXWAhqtRh44gpaB1sZz3Dwlq2Asdw80rBpr
Ti0YItI3hK4O4OK5/wyECd2fqK1+dzCQ5q8o8XbP9LdSbM4vYy/t5S2ZsGuA9zNK
7DKPC6FqFjCQ+LMEt7Fb5E7yDSAnz6QlTscUh7aWz7u7WkYddB7Yy2gEp1FJALhZ
P7kkuIGU+mftZIXqWdxazPc6vygSn0oik66dtaI=
-----END CERTIFICATE REQUEST-----
|
Copiare tutto l’output perchè a breve servirà
GENERAZIONE DEL CERTIFICATO
Da un qualsiasi browser richiamare il link della CA Microsoft
http://IP-SERVER-CA/certsrv
Cliccare su Request a Certificate
Cliccare su Advanced Certificate Request
Incollare la CSR quindi Submit come mostrato nell’immagine sovrastante
Se è andato tutto a buon fine dovremmo visualizzare una schermata come quella sovrastante
Collegarsi in RDP al server della CA quindi aprire lo snap-in Certification Authority e cliccare su Pending Request
Dovremmo visualizzare il certificato in pending
Cliccare con il tasto destro sul certificato quindi slezionare All Tasks quindi Issue
Ritornare sulla pagine web della CA nella home quindi cliccare View the status of a pending certificate request
Dovremmo visualizzare la richiesta del certificato come mostrato nell’immagine sovrastante
Selezionare Base 64 encoded quindi cliccare prima su Download Certificate e poi su Download Certificate chain
Spesso il Download del Certificate Chain non funziona correttamente con i nuovi browser e meno di emulare Internet Explorer
Il certificato lo fa scaricare senza problemi ma se proviamo ad aprirlo ci darà il seguente errore:
This file is invalid for user as the following PKCS #7
Quindi per scaricarlo senza avere problemi collegarsi in RDP al server CA ed aprire lo snap-in Certification Authority
Posizionarsi su Issued Certificates quindi individuare il certificato corretto e fare doppio click
Cliccare su Details
Cliccare Copy to File…
Cliccare Next
Selezionare l’opzione Cryptographic Message Syntax Standard – PKCS #7 Certificate (.P7B) quindi Include all certificates in the certification path if possibile
Cliccare Next
Dare il nome al file quindi cliccare Next
Cliccare Finish
CONVERSIONE DEI CERTIFICATI
Copiare entrambe i file generati dalla CA su un server Linux fidato oppure su Nginx Proxy Manager
Io copierò i seguenti file:
wildcard_mypsx.net.cer
chain.p7b
root.cer
nella cartella /etc/ssl/mypsx/
Copierò anche il file wildcard_mypsx.net.key con il seguente comando:
|
0 |
cp wildcard_mypsx.net.key /etc/ssl/mypsx/
|
Posizionarsi quindi nella cartella /etc/ssl/mypsx/ con il comando:
|
0 |
cd /etc/ssl/mypsx/
|
La prima cosa da fare è convertire il file chain.p7b in chain.cer con il seguente comando se è un file binario DER:
|
0 |
openssl pkcs7 -inform DER -in chain.p7b -print_certs -out chain.cer
|
A questo punto all’interno della cartella /etc/ssl/mypsx/ dovremmo avere i seguenti file:
|
0
1
2
3
|
chain.cer - CA intermedia scaricato da “Download CA certificate” o incluso nella chain
root.cer - CA radice scaricato da “Download CA certificate” (la Root)
wildcard_mypsx.net.cer - Certificato server (wildcard) scaricato come Base 64 encoded da “Download certificate”
wildcard_mypsx.net.key - Chiave privata generato da te con OpenSSL
|
Creare il fullchain da importare in Nginx Proxy Manager con il comando:
|
0 |
cat wildcard_mypsx.net.cer chain.cer root.cer > wildcard_mypsx.net.fullchain.pem
|
ATTENZIONE: Ordine importante: server → intermedia (chain) → root (Nginx e NPM si aspettano questa sequenza)
A questo punto abbiamo i due file necessari:
wildcard_mypsx.net.key
wildcard_mypsx.net.fullchain.pem
IMPORTAZIONE DEI CERTIFICATI IN NGINX PROXY MAMANGER
Accedere alla web gui di Nginx Proxy Manager
Selezionare Certificates
Cliccare su Add Certificate quindi selezionare Custom Certificate
Inserire il nome del certificato quindi caricare i due file
wildcard_mypsx.net.key
wildcard_mypsx.net.fullchain.pem
Cliccare Save
TIPS & TRICKS
La Certification Authority (CA) di Microsoft, nelle sue impostazioni predefinite, emette certificati con una validità massima di 1 anno per diversi motivi legati alla sicurezza e alle buone pratiche nella gestione delle PKI.
Posso aumentare la durata dei certificati?
Sì, è possibile modificare:
- la validità del modello di certificato (certificate template) – presenti solo nella CA Enterprise e non in quella Standalone
- la validità massima consentita dalla CA
Tuttavia, Microsoft sconsiglia di superare 2–3 anni, proprio per i motivi elencati sopra.
Esiste una chiave di registro specifica sulla CA Standalone Microsoft che controlla la validità massima dei certificati che la CA può emettere, inclusi quelli generati da CSR.
Ed è l’unica impostazione da configurare sulla CA per consentire certificati più lunghi.
✅ Le chiavi di registro da modificare
Percorso:
|
0 |
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Nome_CA>\ |
Le due chiavi che controllano la durata massima sono:
ValidityPeriod: Valore: “Years” oppure “Months” o “Days”
ValidityPeriodUnits: Numero degli anni/mesi/giorni (es. 5 = 5 anni)
Aumentare la validità massima a 5 anni da riga di comando
E’ possibile farlo anche da riga di comando:
|
0
1
|
certutil -setreg ca\ValidityPeriod "Years"
certutil -setreg ca\ValidityPeriodUnits 5
|
Poi riavviare il servizio della CA:
|
0
1
|
net stop certsvc
net start certsvc
|
CONSIDERAZIONI FINALI
La generazione di un certificato wildcard tramite la Certification Authority di Microsoft e la sua integrazione in Nginx Proxy Manager offre un notevole vantaggio in termini di gestione e sicurezza dell’infrastruttura.
Centralizzare l’emissione dei certificati permette infatti di mantenere un controllo più rigoroso sulle identità digitali della rete, semplificando al tempo stesso l’amministrazione dei servizi esposti tramite reverse proxy.
Implementare questa soluzione significa ridurre la complessità, evitare certificati duplicati o disallineati e garantire un livello di affidabilità superiore, soprattutto in ambienti aziendali strutturati.
Inoltre, l’utilizzo di un certificato wildcard permette una maggiore flessibilità nell’aggiunta di nuovi servizi, offrendo una configurazione più snella e facilmente scalabile.
In definitiva, combinare la robustezza della CA Microsoft con la comodità di Nginx Proxy Manager rappresenta un approccio efficace per chi cerca una soluzione professionale, sicura e facilmente manutenibile.
Se implementato correttamente, questo setup diventa un tassello fondamentale per una gestione moderna della propria infrastruttura web.
0 commenti