diff --git a/README.md b/README.md
index 81b80d34cf484c3acfa6c452c4385af1b1c15a15..7a0b54c76350da8434a9dace0041a619f16f23ef 100644
--- a/README.md
+++ b/README.md
@@ -85,8 +85,7 @@ Apache-Config sollte irgendwie ungefaehr wie folgt aussehen:
 
 ```
 <VirtualHost _default_:443>
-        Use SSLConfig
-	Header set Cache-Control "no-store, must-revalidate"
+	Use SSLConfig
 	# DANGER: remember to add a new certificate in time with a second pin-sha256 statement:
 	# for testing: only valid for 1h
 	Header add Public-Key-Pins "pin-sha256=\"Kifsh84a1clurPq6mVDx+O8gbeSPA3zCGXalMAfto6k=\"; max-age=3600"
@@ -94,15 +93,17 @@ Apache-Config sollte irgendwie ungefaehr wie folgt aussehen:
 ```
 
   - includeSubDomains kann man angeben (mit `;` getrennt nach `max-age`), ist aber meistens eine schlechte Idee, da es hierarchisch weiter unten stehende Webseiten kaputtmacht.
-  - max-age sollte eigentlich laenger 3600s sein.
-  - Man sollte mehrere Pins angeben um Reserve-Zertifikate zu haben. Diese erzeugt man wie folgt:
+  - max-age sollte eigentlich laenger 3600s sein. Aber, wenn mal ein Schluessel
+    kompromittiert wurde, koennte ein zu langes max-age Benutzer aussperren. 
+    Man sollte daher mehrere Pins angeben und Reserve-Schluessel zu haben. Diese
+    erzeugt man wie folgt:
 
 ```
 openssl genrsa -out ${TARGET}.key.reserve-rsa4096 4096
 openssl rsa -in ${TARGET}.key.reserve-rsa4096 -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
 ```
 
-    Falls das eigentliche Zertifikat dann mal kompromittiert wird kann man den Reserve-Key um wie ganz oben beschrieben einen CSR zu erzeugen verwenden.
+    Falls das eigentliche Zertifikat dann mal kompromittiert wird kann man den Reserve-Schluessel um wie ganz oben beschrieben einen CSR zu erzeugen verwenden.
   - Als Absicherung gegen diverse Versionen der kommenden Cryptocalypse kann
       man noch andere Typen dazuerzeugen: