AbramS
Basic Pleskian
Recently had to replace an expiring SSL certificate which was linked directly to a dedicated IPv4 and IPv6 as it's used for the server's hostname, imapd, smtpd and Plesk panel.
1. Created the new certificate as usual: certificate + most recent PostiveSSL_Bundle as provided by the party that has always generated by certificates.
2. Certificate is recognised as expected. No errors and: Domain Control Validated; PositiveSSL
3. Marked the certificate for use by Plesk Panel.
4. Changed the associated dedicated IPv4 address and IPv6 address in Tools & Settings > IP Addresses to use the new certificate.
Once I then visit the Plesk Panel homepage I'm confronted with the following warning:
New configuration files for the Apache web server were not created due to the errors in configuration templates: nginx: [emerg] BIO_new_file("/usr/local/psa/var/certificates/cert-R9UoOq") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/usr/local/psa/var/certificates/cert-R9UoOq','r') error:2006D080:BIO routines:BIO_new_file:no such file) nginx: configuration file /etc/nginx/nginx.conf test failed . Detailed error descriptions were sent to you by email. Please resolve the issues and click here to generate broken configuration files once again or here to generate all configuration files.
System Overview:
CentOS 6.6 (Final) with Plesk 12.0.18 Update #30
Webserver Configurations Troubleshooter:
Checker: Found errors: 0; Found Warnings: 0
Configurations Show Errors:
ID 9 /var/www/vhosts/system/inspyred.nl/conf/nginx.conf nginxDomainVhost
ID 151 /var/www/vhosts/system/inspyred.nl/conf/nginx_ip_default.conf nginxDomainVhostIpDefault
ID 71 /var/www/vhosts/system/sonnet.inspyred.nl/conf/nginx.conf nginxDomainVhost
How to properly fix this?
Additional information:
Earlier this week I already ran into this problem as the new certificate was generated back then. The first time I used the existing CSR to generate the new certificate and replace the previously existing certificate and CA certificates.
I ended up with the exact same issue and decided to do the following:
1. Follow the suggestions in the "Nginx does not start after IP change" knowledgebase article:
You can fix the issue using the following commands:
# /usr/local/psa/bin/reconfigurator --autoconfigure
# /usr/local/psa/admin/sbin/httpdmng --reconfigure-all
# /etc/init.d/nginx restart
2. I ended up doing a couple of (graceful) restarts of httpd and nginx (and named at some point).
3. I restarted the server.
At that point the warning was no longer being displayed and everything seemed to work ok... Then I started getting emails from watchdog indicating that the Web Server (Apache) and Web Proxy Server (Nginx) were going down and coming up again every now and again.
Weirdly I was unable to see the root processes go down or even the child processes get under 10 instances at any given time through my NewRelic monitor, nor did I receive any 'unable to ping' warnings from Plesk, the datacenter or NewRelic, which I normally do get. Finally, this downtime was not mentioned in the Plesk Monitor iPhone app either...
Because I didn't like the above 'ghost' reports, I had the certificate reissued today, set the related IPs to the default cert, completely removed the old certificate and created a new request with a new CSR. Unfortunately, as stated above, the result is the same.
Update: just had a look in /usr/local/psa/var/certificates/ and the file cert-R9UoOq, which is mentioned in the error, does not exist in that directory. The similar error that I had earlier last week also indicates a missing cert: cert-OHzYte. This file is not in the directory either.
It seems that Plesk is either writing the certificate to the wrong directory/file or isn't at all able to write to the /../certificates/ directory.
Based on the above premise I've done some more digging and have come to a somewhat weird conclusion:
Next to the 'faulty' certificate that I'm discussing here, I've got two more 'real' certificates that were created in the same way and are bound to their own dedicated IPs. After some comparing I found that the files cert-BrS7qJ and cert-m4yxa8 in the /../certificates folder contain the other signed/real certificates that are currently in use. While comparing I also looked at the most recent files created, and guess what: the contents of cert-Djpuzc is actually the new certificate in its entirety.
A couple of things that are of note here:
1. Why are the webservers looking for cert-R9UoOq while the file was saved by Plesk as cert-Djpuzc ?
2. Two of the certificates have Access: (0400/-r--------) with user and group root. One of the working certificates has user/group psaadm - why is there a difference?
3. Finally: I saw that based on the Plesk CSR this new certificate was issued as SHA2, while the older two are SHA1. Can this be an issue? (Guess not as the certificate does work perfectly well for the panel, just not for apache / nginx)
As a temporary fix I've done cp cert-Djpuzc cert-R9UoOq which allowed me to save and apply the configuration.
Finally the details for the discussed files:
New certificate that is causing issues and has the wrong name:
-r--------. 1 root root 10262 Jan 12 21:28 cert-Djpuzc
File: `cert-Djpuzc'
Size: 10262 Blocks: 24 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 134439 Links: 1
Access: (0400/-r--------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2015-01-12 21:28:11.001374506 +0100
Modify: 2015-01-12 21:28:07.578355087 +0100
Change: 2015-01-12 21:28:07.595355182 +0100
The older (functioning) certificates:
-r--------. 1 psaadm psaadm 7805 Sep 3 20:31 cert-BrS7qJ
File: `cert-BrS7qJ'
Size: 7805 Blocks: 16 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 151229 Links: 1
Access: (0400/-r--------) Uid: ( 500/ psaadm) Gid: ( 500/ psaadm)
Access: 2015-01-12 14:26:08.000905608 +0100
Modify: 2014-09-03 20:31:29.068485520 +0200
Change: 2015-01-12 14:19:13.669572491 +0100
-r--------. 1 root root 7871 Sep 3 20:31 cert-m4yxa8
File: `cert-m4yxa8'
Size: 7871 Blocks: 16 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 152997 Links: 1
Access: (0400/-r--------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2015-01-11 23:03:12.012413236 +0100
Modify: 2014-09-03 20:31:29.069485526 +0200
Change: 2014-09-03 20:31:29.069485526 +0200
1. Created the new certificate as usual: certificate + most recent PostiveSSL_Bundle as provided by the party that has always generated by certificates.
2. Certificate is recognised as expected. No errors and: Domain Control Validated; PositiveSSL
3. Marked the certificate for use by Plesk Panel.
4. Changed the associated dedicated IPv4 address and IPv6 address in Tools & Settings > IP Addresses to use the new certificate.
Once I then visit the Plesk Panel homepage I'm confronted with the following warning:
New configuration files for the Apache web server were not created due to the errors in configuration templates: nginx: [emerg] BIO_new_file("/usr/local/psa/var/certificates/cert-R9UoOq") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/usr/local/psa/var/certificates/cert-R9UoOq','r') error:2006D080:BIO routines:BIO_new_file:no such file) nginx: configuration file /etc/nginx/nginx.conf test failed . Detailed error descriptions were sent to you by email. Please resolve the issues and click here to generate broken configuration files once again or here to generate all configuration files.
System Overview:
CentOS 6.6 (Final) with Plesk 12.0.18 Update #30
Webserver Configurations Troubleshooter:
Checker: Found errors: 0; Found Warnings: 0
Configurations Show Errors:
ID 9 /var/www/vhosts/system/inspyred.nl/conf/nginx.conf nginxDomainVhost
ID 151 /var/www/vhosts/system/inspyred.nl/conf/nginx_ip_default.conf nginxDomainVhostIpDefault
ID 71 /var/www/vhosts/system/sonnet.inspyred.nl/conf/nginx.conf nginxDomainVhost
How to properly fix this?
Additional information:
Earlier this week I already ran into this problem as the new certificate was generated back then. The first time I used the existing CSR to generate the new certificate and replace the previously existing certificate and CA certificates.
I ended up with the exact same issue and decided to do the following:
1. Follow the suggestions in the "Nginx does not start after IP change" knowledgebase article:
You can fix the issue using the following commands:
# /usr/local/psa/bin/reconfigurator --autoconfigure
# /usr/local/psa/admin/sbin/httpdmng --reconfigure-all
# /etc/init.d/nginx restart
2. I ended up doing a couple of (graceful) restarts of httpd and nginx (and named at some point).
3. I restarted the server.
At that point the warning was no longer being displayed and everything seemed to work ok... Then I started getting emails from watchdog indicating that the Web Server (Apache) and Web Proxy Server (Nginx) were going down and coming up again every now and again.
Weirdly I was unable to see the root processes go down or even the child processes get under 10 instances at any given time through my NewRelic monitor, nor did I receive any 'unable to ping' warnings from Plesk, the datacenter or NewRelic, which I normally do get. Finally, this downtime was not mentioned in the Plesk Monitor iPhone app either...
Because I didn't like the above 'ghost' reports, I had the certificate reissued today, set the related IPs to the default cert, completely removed the old certificate and created a new request with a new CSR. Unfortunately, as stated above, the result is the same.
Update: just had a look in /usr/local/psa/var/certificates/ and the file cert-R9UoOq, which is mentioned in the error, does not exist in that directory. The similar error that I had earlier last week also indicates a missing cert: cert-OHzYte. This file is not in the directory either.
It seems that Plesk is either writing the certificate to the wrong directory/file or isn't at all able to write to the /../certificates/ directory.
Based on the above premise I've done some more digging and have come to a somewhat weird conclusion:
Next to the 'faulty' certificate that I'm discussing here, I've got two more 'real' certificates that were created in the same way and are bound to their own dedicated IPs. After some comparing I found that the files cert-BrS7qJ and cert-m4yxa8 in the /../certificates folder contain the other signed/real certificates that are currently in use. While comparing I also looked at the most recent files created, and guess what: the contents of cert-Djpuzc is actually the new certificate in its entirety.
A couple of things that are of note here:
1. Why are the webservers looking for cert-R9UoOq while the file was saved by Plesk as cert-Djpuzc ?
2. Two of the certificates have Access: (0400/-r--------) with user and group root. One of the working certificates has user/group psaadm - why is there a difference?
3. Finally: I saw that based on the Plesk CSR this new certificate was issued as SHA2, while the older two are SHA1. Can this be an issue? (Guess not as the certificate does work perfectly well for the panel, just not for apache / nginx)
As a temporary fix I've done cp cert-Djpuzc cert-R9UoOq which allowed me to save and apply the configuration.
Finally the details for the discussed files:
New certificate that is causing issues and has the wrong name:
-r--------. 1 root root 10262 Jan 12 21:28 cert-Djpuzc
File: `cert-Djpuzc'
Size: 10262 Blocks: 24 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 134439 Links: 1
Access: (0400/-r--------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2015-01-12 21:28:11.001374506 +0100
Modify: 2015-01-12 21:28:07.578355087 +0100
Change: 2015-01-12 21:28:07.595355182 +0100
The older (functioning) certificates:
-r--------. 1 psaadm psaadm 7805 Sep 3 20:31 cert-BrS7qJ
File: `cert-BrS7qJ'
Size: 7805 Blocks: 16 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 151229 Links: 1
Access: (0400/-r--------) Uid: ( 500/ psaadm) Gid: ( 500/ psaadm)
Access: 2015-01-12 14:26:08.000905608 +0100
Modify: 2014-09-03 20:31:29.068485520 +0200
Change: 2015-01-12 14:19:13.669572491 +0100
-r--------. 1 root root 7871 Sep 3 20:31 cert-m4yxa8
File: `cert-m4yxa8'
Size: 7871 Blocks: 16 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 152997 Links: 1
Access: (0400/-r--------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2015-01-11 23:03:12.012413236 +0100
Modify: 2014-09-03 20:31:29.069485526 +0200
Change: 2014-09-03 20:31:29.069485526 +0200
Last edited: