Long story short (about revoking):
It hardly ever does anything to correct an ongoing problem [as experienced here].
One should never revoke a cert for reasons other than the ones expressed in the first paragraph here:
2 Likes
@webprofusion I'm currently using your utility and it is making things much easier for me. Thank you! I do have questions though if I may.
If I want to modify a certificate, what would the proper route be? I experienced an issue with applying a wildcard certificate to Remote Desktop services, the client wouldn't accept that the certificate was for *.noxillio.dev, so I recreated a certificate as just noxillio.dev instead and it worked perfectly. But then I'm leftover with the *.noxillio.dev certificate which will now go completely unused. Would it not make sense to revoke it? Or should I just let it expire and then delete it from the store? Is there a better way that I should be making adjustments like that?
2 Likes
No [not for that reason only].
If you are certain that you won't need it, you should just delete it.
[if you leave it, it might get renewed automatically]
When there are many ways to handle things, "better" is usually subjective.
I say: "If it is doing what you need, then it is good (enough)."
[Which is along the lines of: "If it ain't broke, don't fix it!"]
3 Likes
"Cleaner" would probably be a better word for what I'm looking for there. So basically, just done in a way so that extra certificates won't be created. If that's not possible it's alright.
1 Like
Certificates are permanent in the public system. See https://crt.sh/ to view the CT log.
They cannot be modified or deleted once issued. Revoking only "marks them" revoked. It does not remove them or otherwise "clean up" anything.
You can delete them from your server if you don't need them. The method for that depends on the ACME client and system you are on.
3 Likes
In Certify The Web if you just want to adjust the included domains (or add/remove a wildcard) then you click on your managed certificate in the app, select the "Certificate" tab and add/remove the domain from the Domains list, you can then click "Request Certificate" to perform your certificate order etc again. This saves you setting up a whole new cert and having to configure tasks etc again.
In general you wouldn't revoke a previous certificate unless your private key has been compromised or some other important reason, you wouldn't revoke a cert normally just because you're renewing etc.
Note also that for hMailServer I think you need the cert as 2 files (certificate chain and private key) so I'd suggest using the "Deploy to Generic Server" task and set the parameters for the output file paths (key and fullchain file) that way you don't have to do extra work to convert the certificate from PFX. You then also need a task to Restart the hMailServer service.
For Remote Desktop Gateway you may be able to use the built in "Deploy to RDP Gateway" task which basically runs this powershell script (or you could adapt your own script). Again make sure to restart the service to apply the cert: https://github.com/webprofusion/certify-plugins/blob/development/src/DeploymentTasks/Core/Providers/Assets/RDPGatewayServices.ps1
The benefit of automating the deployment steps to your various services using scripting/tasks is that your cert will need to be renewed at least every 90 days and automation means you don't have to manually perform or the steps or remember how it all works.
2 Likes
I'm glad you mentioned hMailServer, as I was having issues trying to set up DKIM earlier. I suppose I'm overcomplicating things by trying to use my LE cert with it, basically the issue was that the public key kept coming back as invalid. Might just use OpenSSL instead and leave it at that, especially since it doesn't expire or need renewal anyway. Maybe I'm misunderstanding some concept.
I did get it working with Remote Desktop. I'm just using the standard RDP setup that comes built-in and CTW did correctly configure the certificate which is great because I would have spent far too much time trying to figure that out on my own. A full RDS setup would require me to pay a ridiculous amount of money for licenses just to be able to use it and I don't really feel like doing that so I'm just sticking with the basic RDP support the OS comes with.
1 Like
I don't know much about DKIM myself but as far as I do know it doesn't typically involve/require a (domain validated) Let's Encrypt certificate and instead I think the private key is just an arbitrary key you have generated and stored (which you can do with OpenSSL, the configure your mail server to sign messages using that key) and the corresponding public key is published as a DNS record. You could probably (?) use the same key as your LE cert but I don't think there's any particular reason to do that.
3 Likes
Yeah, I know. I figured it might be fun/easier to just use the LE cert, but it ended up actually being a waste of time and not working in the end, won't be trying it again.
The actual truth of the matter is that you, or LE, cannot modify a certificate. You can only issue a new one.
You can eventually use the same keypair, but it will be a fundamentally different certificate from the previous one.
ACME clients see the two as parent and successor, implementing the transition gracefully: that's entirely client-side logic.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.