Let’s Encrypt proxy invers

Apunts breus sobre els problemes que he tingut configurant Let’s Encrypt amb un proxy invers i diferents màquines.

Els fitxers de renovació es troben a: /etc/letsencrypt/renewal

Virtualhosts a la mateixa màquina

No s’ha de fer res especial, que el Certbot renovi per Webroot i prou.

Un exemple de fitxer de renovació:

# renew_before_expiry = 30 days
version = 0.10.2
archive_dir = /etc/letsencrypt/archive/lanpartyripoll.cat
cert = /etc/letsencrypt/live/lanpartyripoll.cat/cert.pem
privkey = /etc/letsencrypt/live/lanpartyripoll.cat/privkey.pem
chain = /etc/letsencrypt/live/lanpartyripoll.cat/chain.pem
fullchain = /etc/letsencrypt/live/lanpartyripoll.cat/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = XXXXXXXXXXXXXXXXXXXXXXXXXX
[[webroot_map]]
www.lanpartyripoll.cat = /var/www/lanpartyripoll.cat
lanpartyripoll.cat = /var/www/lanpartyripoll.cat

 

Virtualhosts a diferent màquina

Primer de tot he definit un subdomini apuntant a la màquina que conté el proxy invers. Li he “assignat” els sites default i default-ssl. Aquests sites tenen com a root configurat /var/www/quill. Partint d’aquí, el fitxer de renovació:

# renew_before_expiry = 30 days
version = 0.10.2
archive_dir = /etc/letsencrypt/archive/aniolmarti.cat
cert = /etc/letsencrypt/live/aniolmarti.cat/cert.pem
privkey = /etc/letsencrypt/live/aniolmarti.cat/privkey.pem
chain = /etc/letsencrypt/live/aniolmarti.cat/chain.pem
fullchain = /etc/letsencrypt/live/aniolmarti.cat/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = XXXXXXXXXXXXXXXXXXXXXX
[[webroot_map]]
www.aniolmarti.cat = /var/www/quill
blog.aniolmarti.cat = /var/www/quill
aniolmarti.cat = /var/www/quill
quill.aniolmarti.cat = /var/www/quill

A la màquina on hi ha allotjada la web cal modificar l’.htaccess:

Redirect 301 /.well-known http://quill.aniolmarti.cat/.well-known

 

Casos especials

En un subdomini hi tinc un Trac protegit per autenticació HTTP, això provoca que el client d’ACME no pugui accedir-hi i per tant no ho pugui verificar. Això em passa amb el domini xarxacatala.cat.

Primer de tot cal modificar el site del nginx:

 location ^~ /.well-known/acme-challenge/ {
     root /var/www/xarxacatala.cat;
 }

Amb això canviem l’arrel del directori de verificació del subdomini a la del domini principal, que no està protegit per autenticació HTTP.

El fitxer de renovació:

# renew_before_expiry = 30 days
version = 0.10.2
archive_dir = /etc/letsencrypt/archive/xarxacatala.cat
cert = /etc/letsencrypt/live/xarxacatala.cat/cert.pem
privkey = /etc/letsencrypt/live/xarxacatala.cat/privkey.pem
chain = /etc/letsencrypt/live/xarxacatala.cat/chain.pem
fullchain = /etc/letsencrypt/live/xarxacatala.cat/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = XXXXXXXXXXXXXXXXXXXXXX
[[webroot_map]]
www.xarxacatala.cat = /var/www/xarxacatala.cat
xarxacatala.cat = /var/www/xarxacatala.cat
gestio.xarxacatala.cat = /var/www/xarxacatala.cat

Pegat proxy invers amb WordPress

Avui he estat mirant de canviar algunes configuracions del servidor i em trobava que amb un nginx (HTTPS) fent de proxy invers cap a un Apache servint un WordPress el navegador responia amb un error de problema de redirecció. Per arreglar-ho només cal afegir unes línies al fitxer wp-config.php.

Busquem la línia define('WP_DEBUG', false); i just després afegim:

// Codi pel proxy invers
if ( $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) {
 $_SERVER['HTTPS'] = 'on';
 $_SERVER['SERVER_PORT'] = 443;
}

UnattendedUpgrades – Debian

unattended-upgrades és un paquet que permet realitzar automàticament les actualitzacions del sistema. Per fer-ne una configuració molt bàsica que ni tan sols ens avisi per correu-e és molt simple.

Instal·lem el paquet:

# apt-get install unattended-upgrades

Editem el fitxer /etc/apt/apt.conf.d/20auto-upgrades:

// Enable the update/upgrade script (0=disable)
APT::Periodic::Enable "1";

// Do "apt-get update" automatically every n-days (0=disable)
APT::Periodic::Update-Package-Lists "1";

// Do "apt-get upgrade --download-only" every n-days (0=disable)
APT::Periodic::Download-Upgradeable-Packages "1";

// Run the "unattended-upgrade" security upgrade script
// every n-days (0=disabled)
// Requires the package "unattended-upgrades" and will write
// a log in /var/log/unattended-upgrades
APT::Periodic::Unattended-Upgrade "1";

// Do "apt-get autoclean" every n-days (0=disable)
APT::Periodic::AutocleanInterval "7";

Reiniciem el servei:

# systemctl restart unattended-upgrades

Instal·lar LAMP a Debian 9

Instal·lar serveis

Apache:

# apt install apache2 apache2-mod-php7.0 ssl-cert

PHP:

# apt install php7.0 libapache2-mod-php7.0 php7.0-mysql php7.0-gd php7.0-opcache

MariaDB:

# apt install mariadb-client mariadb-server

Phpmyadmin:

# apt install phpmyadmin

Configuracions

Assegurem la instal·lació de MariaDB:

# mysql_secure_installation

És ben lògic què cal respondre a les preguntes.

Donem accés total a l’usuari phpmyadmin:

# mysql -u root -p
> GRANT ALL PRIVILEGES ON *.* TO 'phpmyadmin'@'localhost' WITH GRANT OPTION;
> FLUSH PRIVILEGES;

I fet.

Pegat opendkim a Debian Stretch

Actualitzant un servidor de correu-e a Debian Stretch els missatges van deixar d’estar signats amb DKIM. Després d’investigar vaig arribar a la conclusió que tal com està configurat el servei a SystemD l’opendkim es passa el fitxer de configuració per l’arc de triomf.

Primer de tot creem el directori del PID i donem els permisos que toquen:

# mkdir /var/spool/postfix/opendkim# adduser opendkim postfix# adduser postfix opendkim# chown opendkim:postfix /var/spool/postfix/opendkim

Per solucionar el problema cal editar dues línies del fitxer /lib/systemd/system/opendkim.service:

PIDFile=/var/spool/postfix/opendkim/opendkim.pid
ExecStart=/usr/sbin/opendkim -x /etc/opendkim.conf -P /var/spool/postfix/opendkim/opendkim.pid -p local:/var/spool/postfix/opendkim/opendkim.sock

Finalment cal reiniciar el servei:

# systemctl daemon-reload
# systemctl start opendkim.service

Font: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853769