Posts Tagged ‘Apache’

Implemented stronger Diffie-Hellman encryption thanks to “Logjam”

Well, I haven’t written anything in a while so I figured I’d put this into WP. I recently upgraded a couple of my iOS devices to 8.4 and sure enough, I couldn’t send emails. Come to find out, my services at home were using weaker DH encryption and I needed to fix them if I wanted to send email ever again from my iPhone.

First I worked on sendmail. I needed to first create a DH 2048 bit file using openssl:

openssl dhparam -out dh_2048.pem -2 2048

This produced a file in my /etc/pki/tls/certs folder which I can now configure to use via adding this line:

define(`confDH_PARAMETERS', `/etc/pki/tls/certs/dh_2048.pem')

Next you can do a ‘make -C /etc/mail’ or simply restart sendmail as it will detect the changes and do it for you (did for me at least.) Email was now working as expected and I’m no longer seeing this in my /var/log/maillog folder:

Aug 1 11:01:10 Sauron sendmail[11796]: t71F0eh9011796: [] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Aug 1 11:01:11 Sauron sendmail[11803]: STARTTLS=server, error: accept failed=0, SSL_error=5, errno=0, retry=-1
Aug 1 11:01:11 Sauron sendmail[11803]: t71F1Ae8011803: [] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Aug 1 11:01:11 Sauron sendmail[11804]: STARTTLS=server, error: accept failed=0, SSL_error=5, errno=0, retry=-1
Aug 1 11:01:11 Sauron sendmail[11804]: t71F1BBU011804: [] did not issue MAIL/EXPN/VRFY/ETRN during connection to TLSMTA

Now to take a look at Apache. I’m using an older version, I think 2.2.3-91 w/ CentOS so there’s only so much I can do regarding MITM attacks apparently. But I can explicitly tell Apache to NOT use weaker encryption protocols even though I can’t use the SSLOpenSSLConfCmd DHParameters “{path to dhparams.pem}” option and specify my DH key.

Here’s what I did put in my ssl.conf file:

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on


Which will at least help for now.


Here’s a couple of useful links:



PHP error w/ move_uploaded_file…

  So way back in the beginning I developed a simple web file manager for our company that allowed us to upload files to a Linux server and share them w/ noncorporate users. Things worked great but I’ve been left maintaining the server even though I’m now playing Network Engineer.

  Well, as time has progressed, the requirement to upload ever bigger files has ballooned and it orginally was built for files around 500MB. So I did a quick php -i | grep php.ini to find where my php.ini file was and started editing the config. I quickly found upload_max_filesize and increased it to over a 1GB for file uploads. Next I found post_max_size and increased that to the same size. Quick restart of the apache server and I was off testing. Started to do some large file uploads and I started getting some errors. I placed some debug code in my php subroutine and low and behold, I was getting an error = 2. This particular error meant I hadn’t increased the HTML form attribute MAX_FILE_SIZE to 1GB either. Once I had all three attributes set to a higher setting I was GTG.

Couple quick links:

Talks about the HTML form input field MAX_FILE_SIZE:

PHP move_uploaded_file function call over on Has LOTS of good demo code below:

Actual PHP file upload errors one can get when using move_uploaded_file:

quick tips!


Moving lots of data:I do all sorts of networking related stuff and one of the few things I do often are server migrations. So eventually, there comes a time for me to copy a large amount of data from one server to another while maintaining the file permissions and structure. That’s where tar & ssh come into play. If I’m moving a users’ home directory from one server to another I usually use tar & ssh together via a pipe and let it copy off the files perfectly.

tar zcvf - jsmith | ssh "destinations IP" "cd /home/; tar zpxvf -"

Within seconds of the command starting off, you’ll be asked for the password for your ssh session. Then, the data will get flung across the network to the destination folder. Works great!

Verifying Apache Configuration:When adding additional Virtual Hosts to your Apache config file it’s nice to make sure they’ve been picked up correctly (or! that you’ve modified the right httpd.conf file!) A simple way of letting Apache tell you what it’s going to use is via the -t option.

httpd -t -D DUMP_VHOSTS

It parses the running configuration and dumps the virtual hosts a nice readable format. You can also use “DUMP_MODULES” to see a list of the modules it will use which can be useful for whether or not that database module is going to be loaded or not.

MySQL database dump:It never fails, when doing a migration you’re going to need to dump your databases from a MySQL DB into another DB on your newer system. If they’re the same version however you can run mysqldump w/ a couple command-line switches and then import them on the new server.

mysqldump -u root -p --databases "your DB here" > dbfilename.sql

After you’ve moved your database file to the new server you can then import it in via:

mysql -u root -p -D "your DB here" < /path/to/dbfilename.sql

Keep in mind, we’re assuming you’ve already created the database inside your new MySQL server and will assign it proper permissions so your end user can connect to it!

Just a couple quickies for today’s post.

As always, a couple useful links:

Return top
Icons made by Freepik from is licensed by CC BY 3.0