OK Google Mail!

Starting around 11 April Gmail started to mess with the TLS. If in the “send as” settings you had anything in the MX hostname, that does not match what’s going on after your @ and your cert, your mail server got a reject, even if his origin matches the certificate. I had ‘mx.andreybondarenko.com’, had to change to ‘andreybondarenko.com’. I didn’t had touched this settings for ages. Discussion by the link below.

https://support.google.com/mail/thread/39390661?hl=en

Extract PEM certificates and keys from a shared NSS DB

$ certutil -L -d .

Certificate Nickname Trust Attributes

SSL,S/MIME,JAR/XPI

FreeIPA CA CT,C,C

$ certutil -L -d . -a -n ‘FreeIPA CA’ > freeipa.crt

The PEM certificate should now be stored in free-ipa.crt.

To extract the PEM key from key3.db use certutil, pk12util and openssl.

$ certutil -K -d . -a
$ pk12util -o keys.p12 -n ‘FreeIPA Key’ -d .
$ openssl pkcs12 -in keys.p12 -out freeipa.key -nodes

DKIM=temperror

Recently I have checked my messages headers of the mail that comes from the andreybondarenko.com MX and found that Google shows that my DKIM signature is invalid:

Authentication-Results: mx.google.com; dkim=temperror (no key for
 signature) header.i=@andreybondarenko.com;

In the spam score section:

DKIM_SIGNED,T_DKIM_INVALID

However the header itself is present:

DKIM-Filter: OpenDKIM Filter v2.10.3 andreybondrenko.com CE25780BAC
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=andreybondarenko.com; s=default; t=1483634085;
        bh=w00tuUhwty0/5n/YHiopiY3PpnqKT5BLK9l6TkDNUUk=;
        h=Subject:From:Reply-To:To:Date:From;
        b=J5qB5RF9lrOho1wBpLyLi5a6CwIHZK1sugCr2wpwnPKwEg76RFv2/y8xaiwquqftX
         VhTJH9NLJXcPdu8k8/zN/sc8P1RksNR9EvDw6k2YNEKoeMsKMGgyMC4kAAhcT31IgX
         eqnIqWxhVTVdjRqrqzNPn0wuBbGJgO2bwmFcVsy8=

I have found that it’s quite common configuration error of the OpenDKIM, the selector you choose to store key can be chosen randomly, but the TXT record should match /etc/opendkim.conf. In my case:

##  Defines the name of the selector to be used when signing messages.
Selector   default

But the DNS record:

[user@andreybondarenko ~]$ dig TXT mail._domainkey.andreybondarenko.com

;; ANSWER SECTION:
mail._domainkey.andreybondarenko.com. 1800 IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCdGRWtWPPZVIg0fy7Pr0+rsBsoL6Imt1GBE/QRd3X5Izv1iAJFUsOtea
f9TI9EO/YFwoLLahzuoZM1oUU4ED3fHlItEnqXCKQhX8Zripi7gfIO+DRFEhGuQtG6OIuA6+c3ivao7DTPk/IFqY7MG5M3wMvAfV+
eIBf1VjmajSwe3wIDAQAB"

Changing ‘Selector’ to ‘mail’ and restating opendkim (it’s faster then change DNS):

Authentication-Results: mx.google.com; dkim=pass
 header.i=@andreybondarenko.com;

In the spam score section:

DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU

Let’s encrypt cert updates

Let’s encrypt is wonderful, but certificate are getting expired every 3 months. Since it’s a first time I need to renew them, I have done it manually. The tool authenticates you (by default) with special file created in the .well-know/acme-challenge directory of the root, so the blog engine should not interfere or rewrite anything and should not return it’s own 404 page. Historically my nginx.conf has lots of existing redirects and rules, I am too lazy to correct and simplify it, so simple

localtion ~ .well-known {
        allow all;
    }

does not work. And I am too lazy to figure out why it is so (bad for me). So the most simple way to renew certs for me is to switch to minimal config. Putting it here for the future reference.

user  nginx;  
worker_processes  1;
error_log  /var/log/nginx/error.log;
pid        /run/nginx.pid;
events {
    worker_connections  1024;
}
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;
    server_names_hash_bucket_size 128;
    index   index.html index.htm;
    server { listen 80;
        listen [::]:80;
        server_name andreybondarenko.com;
location / {
                 root   /var/www/;
        }

    }
}

Иран

Вобщем, там закрыли HTTPS. Теперь они не могут завести в поддержке инцидент, так как логин по HTTPS, и активировать продукт они тоже не могут, так как для активации тоже нужен HTTPS. Ну и зачем они это сделали?