PCI was failing due to expired certificates on TCP ports: smtp (25), urd (465), imaps (993) and pop3s (995)
System running Plesk 9.2 and imaps and pop3s was handled by courier.
Updated the self signed certs for courier pop3s and imaps by:
[bash]# cd /usr/share/courier-imap
[bash]# cp imapd.pem imapd.pem.old
[bash]# cp pop3d.pem pop3d.pem.old
[bash]# ./mkimapdcert
[bash]# ./mkpop3dcert
[bash]# /etc/init.d/courier-imap restart
Stopping Courier-IMAP server:
$ Stopping imap done
$ Stopping imap-ssl done
$ Stopping pop3 done
$ Stopping pop3-ssl doneStarting Courier-IMAP server:
$ Starting imapd done
$ Starting imap-ssl done
$ Starting pop3 done
$ Starting pop3-ssl done
Then, tested from a remote machine. Used the nagios check_tcp command:
[bash]# /usr/local/nagios/libexec/check_tcp -H hostname -S -p 993 -D 1
OK – Certificate will expire on 02/26/2011 12:46.[bash]# /usr/local/nagios/libexec/check_tcp -H hostname -S -p 995 -D 1
OK – Certificate will expire on 02/26/2011 12:01.
Looks good.
Now, port 465 TCP was urd according to one of the hosts, but, it’s smtps. We are using qmail on this system. The certificate could be found in /var/qmail/control.
# /usr/local/nagios/libexec/check_tcp -H hostname -S -p 465 -D 1
CRITICAL – Certificate expired on 02/09/2010 15:15.
CRITICAL – Cannot retrieve server certificate.
# cd /var/qmail/control
# cp servercert.pem servercert.pem.old
# openssl req -newkey rsa:1024 -x509 -nodes -days 3650 -out servercert.pem -keyout servercert.pem
and fill in the questions. Restart xinetd and test again.
# /usr/local/nagios/libexec/check_tcp -H hostname -S -p 465 -D 1
OK – Certificate will expire on 02/24/2020 13:23.
TCP OK – 0.070 second response time on port 465|time=0.070008s;;;0.000000;10.000000
Using Postfix with Plesk? Well, this is untested as Plesk 9.3 implementation of Postfix was broken in many ways and we had to stay with qmail until resolved…. months later; still waiting. (Perhaps 9.5 fixed it?)
Finding the cert file:
# grep smtpd_tls_cert /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/postfix/postfix_default.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
So, I guess we want to update: /etc/postfix/postfix_default.pem
# cp /etc/postfix/postfix_default.pem /etc/postfix/postfix_default.pem.orig
# openssl req -newkey rsa:1024 -x509 -nodes -days 3650 \
-out /etc/postfix/postfix_default.pem \
-keyout /etc/postfix/postfix_default.pem# /etc/init.d/postfix restart
Do your testing to make sure it has worked fine.
URLs:
5 responses so far ↓
1 PCI compliance for Plesk 9.x; medium strength SSL ciphers | Stuff... // Mar 5, 2010 at 10:33 am
[...] PCI expiring SSL certificates with Plesk [...]
2 Zack // May 18, 2010 at 12:59 am
This would have taken my a while to figure out if it had not been for your article. Thanks very much, dealing with PLESK can be very troublesome.
Could you also include a HOW-TO for refreshing the certificate if using postfix?
3 john // May 18, 2010 at 9:43 am
Hey Zack, Thanks for your message. I have updated the article to include Postfix. We didn’t use postfix as it had many issues up to and including Plesk 9.3. Hope the update helps… please note, I’ve not tested it but it should work.
4 Zack // May 26, 2010 at 2:00 am
John, I confirm this worked on our client who runs postfix. Note that we swtich to postfix as a workaround to PCI’s latest grievance about qmail not using “netqmail”, even though PLESK manually applies all the patches of netqmail.
qmail is far more reliable than postfix, even in the newest 9.5.X series of PLESK.
5 john // May 26, 2010 at 12:17 pm
Hey Zack, thanks for confirming that the update for postfix worked.
I prefer postfix in general mainly because to me the logging is a bit easier to understand, however, the Plesk implementation of Postfix MTA support is a dogs dinner and gives postfix a bad name.
Leave a Comment