• The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Expired SSL certificate keeps showing

@Ruben Yeah! Excellent. No probs with the posts etc, it was a mystery that just neeed to be solved ;) Interesting that, effectively, it was specific to restarting sw_cp_server itself. There have been 'challenges' with doing just that, previously** but it's definitely improved since the old Plesk Onyx days. In all the excitment, we both missed the obvious server re-boot (I think) because that would / should have achived the same as that link, but by default, but a server re-boot is normally never required just for certificate placements, so... Itt's solved now. That's the key thing. Maybe you can change this thread status to "Resolved" - for any future readers?

** FWIW A long time ago now, back in early challenging Onyx days, we had issues with sw_cp_server but not exactly the same as you've just experienced. Back then, another user, very kindly, sent us the valid comment below, which we have used since (on a couple of occasions) and which may also have been useful / valid for your last "challenge", but, for some reason we overlooked mentioning it :oops: Sorry!

"...There’s no need to restart the complete sw-cp-server. Required Terminal Code:

/etc/init.d/sw-cp-server stop
/etc/init.d/sw-cp-server start

Note there’s no use of restart. When you issue a restart some daemons will check the new config before stopping. If it rejects the config, it will not stop the daemon and continue using the old config. This may be good from a reliability point of view, but you should take that in consideration when using restart.... A situation with an invalid config may bite you many days (weeks, months?) later and… You will have no clue why your daemon suddenly doesn’t work…"
 
@learning_curve, maybe you have an insight to an issue I see and which I see others log as an improvement request with Plesk ... I have an expired default cert that refuses to go away!

plesk-certs.png
These are all Let's Encrypt certs which I rename as "FQDN from_date to end_date" ... it helps to know what I'm deailing with. Note FQDN is the name of the server itself, not of any service running on the server.

If you look above the table, you will see the '23-Oct-22 to 21-Jan-23' is allocated to both the Plesk console and the mail/SMTP service (so that any rDNS check on the service all matches). However, in the table you will see the '23-Oct-22 to 21-Jan-23' cert is both the default cert and claimed to be in use by zero services ... despite being assigned to both the console and smtp service right above this table. Meanwhile the expired '03-Jun-22 to 01-Sep-22' cert is claimed to be in use by 1 service, although most unhelpfully, Plesk gives you no clue as to which service it believes is using this cert.

Any ideas on this one? I am quite sure that expired Jun-Sep cert is NOT in use. The only services that use these certs under 'SSL/TLS Certificates' is the console and SMTP and you can see neither are using this cert. The have bene using the Aug-Nov cert for 2.5 months and have now been rotated to the Oct-Jan cert.

Thanks for any advice :)
 
Meanwhile the expired '03-Jun-22 to 01-Sep-22' cert is claimed to be in use by 1 service, although most unhelpfully, Plesk gives you no clue as to which service it believes is using this cert.

Any ideas on this one?
It is most likely used in a subscriber domain, because subscribers have the ability to select any one of the server certificates if they have not installed their own. There is no problem with letting it sit there. Some day the subscriber will notice that his websites throws an error, and when he generates a real, working certificate for his domain, the old one can be removed, because then it is no longer used by anyone.
 
~~~
If you look above the table, you will see the '23-Oct-22 to 21-Jan-23' is allocated to both the Plesk console and the mail/SMTP service (so that any rDNS check on the service all matches). However, in the table you will see the '23-Oct-22 to 21-Jan-23' cert is both the default cert and claimed to be in use by zero services ... despite being assigned to both the console and smtp service right above this table. Meanwhile the expired '03-Jun-22 to 01-Sep-22' cert is claimed to be in use by 1 service, although most unhelpfully, Plesk gives you no clue as to which service it believes is using this cert.

Any ideas on this one? I am quite sure that expired Jun-Sep cert is NOT in use. The only services that use these certs under 'SSL/TLS Certificates' is the console and SMTP and you can see neither are using this cert. The have bene using the Aug-Nov cert for 2.5 months and have now been rotated to the Oct-Jan cert.
Check the above post from @Peter Debik but also;
When you added the 23-Oct-22 to 21-Jan-23 Cert, did you fail to apply the "Make Default" option after adding it? That would be another reason for this.
If you did apply the "Make Default" option, then you should see that Cert in your table, with score of 2 (in your case) Plus, you should also be able to confirm this status against your server IPv4 / IPv6 addresses via the **your host server**/admin/ip-address/list/ where you can also apply "Reread IP" option (if needed).
When your correct Cert is the default Cert and is correctly reported as being allocated, you should then be able to remove both of the expired Certs with ease.
 
Back
Top