The Requested nginx Plugin Does Not Appear to Be Installed

In questo caso basterà installare il necesario plugin e poi riprovare:

apt install python3-certbot-nginx

verificare che il plugin sia installato su certbot:

certbot plugins

e riprovare:

certbot --nginx

enjoy!

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Options = UnsafeLegacyServerConnect

ATTENZIONE: per openssl minore di 3.0.4 va utilizzato:

Options = UnsafeLegacyRenegotiation

mentre dalla versione openssl 3.0.4 va utilizzato:

Options = UnsafeLegacyServerConnect

enjoy!

Ipotizziamo di avere smsoft.it.crt e smsoft.it.ca-bundle, per unire questi ceritifcati in un unico file bisogna digitare:

cat smsoft.it.crt smsoft.it.ca-bundle > smsoft.it.ca-combined.crt

e poi avremo nel file di configurazione del VH su nginx:

...
ssl_certificate /etc/nginx/ssl/smsoft.it.ca-combined.crt;
ssl_certificate_key /etc/nginx/ssl/smsoft.it.key;
...

Questo però provoca l’accodamento dei due file, infatti eseguendo:

openssl x509 -text -noout -in smsoft.it.ca-combined.crt

avremo un errore tipo:

unable to load certificate
139998757910160:error:0906D066:PEM routines:PEM_read_bio:bad end line:pem_lib.c:804:

e qualcosa del genere se proviamo a riavviare nginx:

(SSL: error:0906D066:PEM routines:PEM_read_bio:bad end line)

ATTENZIONE: una cosa importante è aprire il file smsoft.it.ca-combined.crt, cercare la riga con scritto:

-----END CERTIFICATE----------BEGIN CERTIFICATE-----

e dividerla in due righe:

-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

ora funzionerà tutto correttamente e potremo riavviare nginx.

enjoy!

dpkg-reconfigure exim4-config

Durante il processo guidato viene chiesto se si vuole eventualmente usare uno smarthost e se quest’ultimo accetta connessioni plain sulla porta 25, non bisogna fare molto altro (oltre configurare i dati di autenticazione in /etc/exim4/passwd.client ).

Se però lo smarthost usa la porta 465 SSL oppure la 587 STARTTLS, allora occorre fare una modifica in più.

Durante la configurazione guidata bisognerà inserire l’indirizzo dello smarthost seguito da ::465 (due volte due punti e poi la porta) oppure ::587.

Va inoltre modificato il file /etc/exim4/exim4.conf.template nella sezione “remote_smtp_smarthost:” aggiungendo:

hosts_require_tls = [indirizzo server smtp]
protocol = smtps

ATTENZIONE: la riga

protocol = smtps 

va inserita solo se si usa SSL, mentre non va inserita per STARTTLS.

sotto la riga:

driver = smtp

avendo quindi qualcosa di questo tipo:

remote_smtp_smarthost:
debug_print = "T: remote_smtp_smarthost for $local_part@$domain"
driver = smtp
hosts_require_tls = mail.example-domain.net
protocol = smtps

Nota: Nel file precedente va inserito solo il nome del server SMTP senza la porta.

ATTENZIONE: la riga

protocol = smtps 

va inserita solo se si usa SSL, mentre non va inserita per STARTTLS.

Aggiorniamo la configurazione di exim con il comando:

update-exim4.conf

Riavviamo exim4 e ci siamo:

service exim4 restart

Per provare l’invio basterà digitare:

echo "Email di test tramite relay" | mail -s "Email di test" user@domain.com

In caso fosse necessario personalizzare l’indirizzo email del mittente, bisognerà usare l’opzione -r, es:

echo "Email di test tramite relay" | mail -r "email@mittente" -s "Email di test" user@domain.com

Per personalizzare il mittente per ogni utente senza doverlo specificare con il parametro -r, si può modificare il file /etc/email-addresses, ad esempio per modificare il mittente di root con noreply@d.ext scriveremo in /etc/email-addresses:

root: noreply@d.ext

enjoy!

In alternativa, ad ordine completato, si può andare sul sito https://secure.trust-provider.com/products/ORDERSTATUSCHECKER selezionare l’opzione “SSL Certificate purchased from a reseller”, confermare e poi inserire il numero d’ordine, il nome a dominio (es *.dominiodavalidare.it) e lasciare il cambio email vuoto. Confermare nuovamente e dalla nuova maschera scegliere il pulsante “Change Method”, poi “Change and Resend/Retry” ed infine cliccare su “Show Alternative DCV Information’ ed andare sul TAB ‘CNAME CSR Hash’.

(fonte)

enjoy!

Per la generazione dei certificati consiglio l’utility certbot-auto. Ricordo i passaggi per l’installazione:

wget https://dl.eff.org/certbot-auto
chmod a+x ./certbot-auto
mv certbot-auto /usr/bin/

Bene, ora per generare un certificato basterebbe (per apache):

certbot-auto -i apache

oppure (per nginx):

certbot-auto -i nginx

mentre se occorre solo generare il certificato:

certbot-auto certonly

e lo script provvederebbe ad elencare i virtualhost trovati chiedendo per quali generare un certificato HTTPS.

Per la generazione di un certificato wildcard bisogna invece digitare:

certbot-auto -i nginx --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns -d *.domain.ext -d domain.ext -d altro.domain2.ext

In questo modo creeremo il certificato per *.domain.ext, domain.ext e altro.domain2.ext

Lo script chiederà di inserire un record DNS TXT per il nostro dominio domain.ext, mostrando un messaggio tipo:

---------------------------------------------------

Please deploy a DNS TXT record under the name

_acme-challenge.domain.ext with the following value:

yIRWjqL-wO35ScQMgIVPkSmQuhGl-g4YRz-9mCU

Before continuing, verify the record is deployed.

---------------------------------------------------

Bene, creiamo il nostro record DNS chiamato _acme-challenge con il valore indicato. Verifichiamo che il record sia propagato e poi confermiamo allo script di proseguire.

Infine, per vedere i certificati attualmente gestiti da certbot-auto, basta digitare:

certbot-auto certificates

Ora non resta che configurare CRON per il rinnovo automatico dei certificati, aggiungendo questa riga:

0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/bin/certbot-auto renew

enjoy!

pip install --upgrade setuptools
pip install --upgrade sslyze

e poi per avviarlo:

python -m sslyze --regular www.smsoft.it

enjoy!

openssl s_client -starttls smtp -showcerts -connect HOST:PORT 2>/dev/null | openssl x509 -noout -dates

oppure per certificato TLS su servizio IMAP:

openssl s_client -starttls imap -showcerts -connect HOST:PORT 2>/dev/null | openssl x509 -noout -dates

HOST:PORT vanno sostituiti con l’indirizzo e la porta del servizio.

enjoy!

E’ possibile configurare wowza anche per usare un certificato SSL e quindi rispondere con protocollo SSL, ma con alcuni certificati ho riscontrato problemi di validazione, con l’errore:
Verify return code: 21 (unable to verify the first certificate)
recuperato con un check (ipotizziamo la porta 1937 configurata per l’SSL):
openssl s_client -showcerts -connect IP_SERVER_WOWZA:1937

Di fatto questo crea problemi nella visualizzazione dei filmati, perché il client non riesce a validare il certificato.

Dato che con apache il certificato funzionava correttamente, la soluzione più veloce è stata quella di configurare Apache come proxy per il server di streaming. Vediamo come.

Innanzitutto abbiamo Apache che funziona correttamente e lo configuriamo per rispondere anche sulla porta 1937, quindi aggiungiamo nel fiel /etc/apache2/ports.conf la direttiva:
Listen 1937

Creiamo un virtualhost che risponda sulla porta 1937, faccia uso del certificato e con la direttiva proxypass configurata:


ServerName stream.miosito.it
ServerAdmin webmaster@localhost

Configuriamo wowza per accettare connessioni sulla 1937 solo da localhost altrimenti non potremo avere sia apache che wowza sulla stessa porta. Modifichiamo nel file /usr/local/WowzaStreamingEngine/conf/VHost.xml la direttiva relativa alla porta in questione e sostituiamo * con 127.0.0.1.

Non dimentichiamo infine che wowza aggiunge l’header, quindi se anche apache aggiunge tale header, dovremo modificare il file /etc/apache2/conf-enabled/security.conf come segue:
Header unset Access-Control-Allow-Origin
Header always set Access-Control-Allow-Origin "*"

enjoy!

Ad esempio, c’è la possibilità di fare un mirror dei files presenti in locale verso il server o vice-versa dal server in locale. La cosa comoda di questa funzionalità è che vengono trasferiti solo i files modificati e per siti grandi è una manna dal cielo.

Questa volta il server risponde con protocollo ftps ed ho notato un comportamento strano di lftp. All’inizio mi ha “detto” di non riuscire a validare il certificato TLS/SSL, perché non legato al nome a dominio:
Certificate verification: certificate common name doesn't match requested host name...

Poco male, ho creato un file di configurazione, esattamente in ~/.lftprc ed ho inserito:
set ssl:check-hostname no
Questo mi ha permesso di bypassare l’errore, ma la connessione comunque non funzionava, continuava a disconnettersi al tentativo di accesso.

A questo punto, l’unica soluzione è fare un debug per vedere cosa succede. Vediamo come procedere.

Per la connessione, si usa la seguente sintassi:
lftp -u username,password IP_O_FQDN_SERVER

Dopo aver digitato questo comando, si accede al prompt di lftp. Per abilitare il debug basta digitare:
debug

Ho poi fatto un ls (per vedere i files presenti sul server) ed ho visualizzato una serie di informazioni con al termine:
...
...
gnutls_record_recv: The TLS connection was non-properly terminated. Assuming EOF.
...
...

Come immaginavo, non digerisce la connessione TLS/SSL. Sempre nel file di configurazione, ~/.lftprc, ho inserito anche:
set ssl-allow false

Bene, ora ci siamo, la connessione funziona correttamente.

enjoy!