deny from all
allow from 18.104.22.168
allow from 22.214.171.124
deny from all
allow from 126.96.36.199
allow from 188.8.131.52
openssl pkcs12 -export -out cert.pfx -inkey privkey -in cert -certfile intermediates
Anyone still using Debian Squeeze? LTS has ended. Do your final update:
deb http://archive.debian.org/debian/ squeeze contrib main non-free
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb http://archive.debian.org/debian squeeze-lts main contrib non-free
# apt-get update -o Acquire::Check-Valid-Until=false
Hello there, here is some Debian Auto-Update 'Copy-Paste-Config' for the impatient:
# apt-get install unattended-upgrades apt-listchanges
# joe /etc/apt/apt.conf.d/50unattended-upgrades
At least edit the mail address so you can receive the neccessary information.
# joe /etc/apt/apt.conf.d/20auto-upgrades
Generate some new private rsa key:
# openssl genrsa -out key 4096
Populate a custom conf-file for using:
distinguished_name = req_distinguished_name
req_extensions = v3_req
countryName = Country Name (2 letter code)
countryName_default = DE
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Baden-Wuerttemberg
localityName = Locality Name (eg, city)
localityName_default = Goeppingen
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = domain.org
commonName_max = 64
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
DNS.1 = domain.org
DNS.2 = autodiscover.domain.org
DNS.3 = exchange.domain.org
DNS.4 = fancy-other-name.domain.org
Check the output
# openssl req -text -noout -in san_domain_com.csr
Generate the CSR for your favorite CA:
# openssl req -sha256 -new -out san_domain_com.csr -key key -config openssl.conf
Download one specific directory as a whole, with ignoring robots.txt, without downloading anything above/below.
# wget -e robots=off -r --no-parent "http://URL/path/"
Just kidding. But there are indeed a few obstacles when you try to introduce DNSSEC with your domain.
- First check that the domain-provider you're with, allows you to put your Keys into the nic database of your country through some webinterface or other automated process. I started off with my default provider telling me: "Ah, thats so rare at the moment, you have to open a support ticket for each change you like. And, you know, if its too much, we'll bill you for the extra service if we please... Anyway, it's not in the webinterface".
Now I'm using http://www.schlundtech.de/ for my DNSSEC secured domains. With them you at least only have to tell them once to enable the DNSSEC-features for your customer id in the interface and you're done.
- The other thing is: You have to administer two DNS servers of and on your own! Make "bind" your friend here.
After passing that hurdle just go with any popular HOWTO available on that topic. I found that one quite good.
After rolling your DNS zone out, of course do some testing. I found two utilities comfotable to use. For your <major browser> to show you if a domain is DNSSEC secured and has the appropriate TLSA record in it, check out DNSSEC validator plugin. For basic zone checking I use the verisign debugger.
Do you know the new hotness in TLS/SSL security regarding webservers? Try HPKP (RFC draft). What's that again? Certificate pinning for your webserver/vhost. Imagine a government or rogue CA creating a valid certificate for your domain and eavesdropping on connections to your server (for whatever specific reason). You can mitigate that by telling visitors of your page (aka their browsers) which certificate to expect. There's a great link to a mozilla developer site that explains it in detail. For short: You extract the fingerprint of your public key you used for the certificate and put that into your http header.Actually HPKP checking is already in Chrome and enabled by default. For FF I see it planned for Jan/2015. Sure, one obstacle remains: Using that technique you rely on "trusted first visit". Well, maybe also consider introducing DNSSEC in your domain(s). But that's another story.
Lately I was trapped in the "initramfs" prompt on a server that was rebooted. The reason for it being stuck there was obivously some hdd change due to raid failure/rebuild. After panicing for a few seconds I tried to fix the situation. I tried two different approaches. Depending on your personal situation one or the other might suffice. One situation could be solved by:
Activate LVM from initramfs prompt
# lvm vgscan
# lvm vgchange -a y
# mount -t ext4 /dev/primary_vg/root_lv /root
(Note to myself: LVM can be enabled/activated in initramfs> prompt if this is the only issue that prevents the system from booting)
Now for the more complex "the ramdisk did not recognize my md-raid right"-situation:
Assemble MD-Raid from initramfs prompt
# rm /etc/mdadm/mdadm.conf
# mdadm --assemble --scan
# mount -t ext4 /dev/md127 /root
Worked and got the system booting, but I couldn't quite fix the initramfs from there. So I restarted back into some rescue system and finally did the following:
(starting from "initramfs>" prompt)
Fix broken initramfs from rescue system
# mkdir /target
# mount /dev/md0 /target
and depending on your partitioning: # mount /dev/md1 /target/boot/
# mount -o bind /dev /target/dev
# mount -o bind /dev/pts /target/dev/pts
# mount -o bind /sys /target/sys
# mount -o bind /proc /target/proc
# chroot /target
# update-initramfs (maybe with opts: -k -t or -u)
Test it by rebooting, and finished.
I recently stumbled upon a problem regarding setting display_errors on/off on a webserver. One of the systems I maintain has configured apache2 with php5.x and suPHP module enabled. In this situation php_flags set in either the vhost or .htaccess files are not effective. Luckily i found out how to deal with that anyway: Just put a separate php.ini (maybe start with a copy from the system-wide one) in the documentroot of the vhost you try to set custom settings with! Voila. Now use that one for your special settings.