let’s encrypt make HTTP requests to a domain for check the ownership.

But, if you have already HTTPS enabled and make a redirect for all HTTP requests like

if ($scheme = 'http') {
	rewrite ^ https://$server_name$request_uri? permanent;
}

then you run into a problem:

Sat Mar 5 16:31:07 CET 2016 Failed authorization procedure. blog.mameso.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://blog.mameso.com/.well-known/acme-challenge/rmKLoxxxxD7h4rxxxxF2wHexxxxLWAPGaxxxxI [213.111.221.123]: 403

So you need to exclude the HTTP reqests to „/.well-known/acme-challenge/*“:

location '/.well-known/acme-challenge' {
	break;
}
location '/' {
	if ($scheme = 'http') {
		rewrite        ^ https://$server_name$request_uri? permanent;
	}
	try_files $uri $uri/ /index.php?$args;
}

The try_files is for WordPress readable URIs.

Thats it – the next let’s crypt ssl-cert updates are running fine.

Anyone with the same problem or you have a better solution? leave a comment!

Nach dem manuellen extrahieren des „~/Library/Mail“ Ordners aus einem TimeMachine Ordner möchte Mail nicht mehr starten.

Die Konsole zeigt das es ein Filesystem Problem gibt – erweiterte Attribute aus dem TimeMachine Filesystem blocken den Zugriff durch „Mail.app“ .

Lösung:
Alle erweiterten Attribute entfernen. Sicherheitshalber noch ein chown und die Filesystemrechte mit dem Festplattendienstprogramm reparieren. Mail sollte dann wieder starten

$root # xattr -r -c /User/meinusername/Library/Mail


$ xattr --help
-c: deletes (clears) all xattrs
-r: act recursively