mirror of
https://github.com/certera-io/certera.git
synced 2026-04-25 03:05:52 +03:00
[GH-ISSUE #15] Can't Change ACME Challenge Type #14
Labels
No labels
bug
feature-request
feature-request
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/certera#14
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @blastagator on GitHub (Oct 20, 2020).
Original GitHub issue: https://github.com/certera-io/certera/issues/15
Originally assigned to: @certeraio on GitHub.
I wanted to change the existing Certera Cert to DNS challenge/validation. When I change the drop down and hit save it does not update. I thought this may be defined behavior for the Certera cert, so I tried making another cert for a different subdomain and then switching the challenge type which also failed.
Is this intended / needed behavior based on how LE works? If so, may want to tweak the drop down box to become grey/unchangeable once a cert is created.
Thanks!
@certeraio commented on GitHub (Oct 20, 2020):
I think this is a bug/omission on my part. Certera originally only did HTTP validation. I added DNS validation much later as a change in the codebase and looks like I forgot to add that ability when editing a cert. I can't see any reason why it can't be changed at will.
I'll flag this as a fix to make for a future release. In the meanwhile, I believe you should be able to delete and create the cert correctly. The key should be retained so that cert-pinning still works. It sucks, but at least that should work as a workaround.
@blastagator commented on GitHub (Oct 20, 2020):
I backed up the certera folder to try your recommendation but trying to delete the site certificate yields "Cannot delete site certificate"
I may try to manually edit the database if I feel super motivated, or I can just make the http server available every 3 months (assuming this isn't fixed by then).
Thanks for helping and responding so fast!
@certeraio commented on GitHub (Oct 21, 2020):
Ah, sorry. I didn't get that it was the certera instance cert itself you were trying to change. I know there are limitations about being able to delete that one vs other certs, as you don't want to be unable to access the site.
I need to go back and double check whether the certera cert itself can be on dns validation. I know it starts off as HTTP since that's part of the initial setup. If you're trying to keep this mostly internal, I can see why you wouldn't want to open access for HTTP. Let me stew on this a bit more to see if having some dns config in place prior to setup would be sufficient to make DNS an option for the instance cert.
@blastagator commented on GitHub (Oct 21, 2020):
Sure thing. I appreciate your help!
I am able to enable http support for the initial setup (and could do it manually for renewals), I'd just really prefer to have it fully automated like all of the other certs. I've also been writing some scripts for my various applications:
Cloudflare add / delete scripts
apache
plex
I'll start up a repo once I have them ironed out the way I like them and I'll share the link in case you (or anyone else using your great server) have interest. I'd love to help with the underlying project, but sadly I am not overly familiar with c or c# (aside from some very basic things).
@certeraio commented on GitHub (Oct 21, 2020):
It may be that the certera instance cert begins as HTTP validation, then it can be changed to DNS manually if the operator chooses (once the bug is fixed). I think that should all work. I'll check it out over the weekend and provide an update here.
As for the scripts, I'm sure it'll be helpful to others. I know there have been a few folks using different DNS providers and applying certs to various systems like nginx, IIS, etc. Thanks for your feedback and community contributions!
@certeraio commented on GitHub (Oct 28, 2020):
@blastagator I've created version 2.1.4 with the fix to change the certificate challenge type. You'll have to open things up for the initial provisioning, but then should be able to change the challenge type and lock things down. Hopefully that's a suitable workaround.
https://github.com/certera-io/certera/releases/tag/2.1.4
@blastagator commented on GitHub (Oct 28, 2020):
Thanks! I installed the new version but after switching to dns challenge type the webui just shows "Error" when I try to request an update. Is there a log location I can check for more specific details? I verified another one of my certs still updates successfully, so the challenge type still seems to be working fine in general.
@certeraio commented on GitHub (Oct 28, 2020):
Check /var/syslog as it should put everything in there. The error will go a long way into figuring it out.
@blastagator commented on GitHub (Oct 28, 2020):
I did a fresh request (to ensure I only captured the logging related to the error) and this is the output:
@certeraio commented on GitHub (Oct 28, 2020):
Hmm, that's not too useful. You may need to change the Default log level in the app settings.json file to be Debug to get a little more info. I was hoping for a line number to make it easier.
I can try to reproduce it tomorrow too.
@blastagator commented on GitHub (Oct 28, 2020):
Here is the log info with Debug level set. I'm not sure this is much more helpful though.
@certeraio commented on GitHub (Oct 28, 2020):
One thing that's interesting is this here: https://acme-v02.api.letsencrypt.org/acme/order/99857896/5908461734
In the identifiers, it says "type": "dns", which is correct.
Then, when you follow the "authorizations" link: https://acme-v02.api.letsencrypt.org/acme/authz-v3/8028529186
It shows http-01 in the challenges. I'm not sure if that's correct or not (if that shows up for all request types or only for HTTP-01). In my test quick test, I can't see much as some of those URLs don't work in when using the staging Let's Encrypt endpoints. I'll keep digging.
@blastagator commented on GitHub (Oct 28, 2020):
Here is the log when I renew a different cert (that is successful):
@certeraio commented on GitHub (Oct 28, 2020):
See how in the authz-v3 URL that the challenges are dns-01 type: https://acme-v02.api.letsencrypt.org/acme/authz-v3/8032295765
I need to see if a cert can be changed from starting under one challenge type and moving to another. I'll do some digging and let you know what I find out.
@certeraio commented on GitHub (Oct 28, 2020):
@blastagator I've created build 2.1.5: https://github.com/certera-io/certera/releases/tag/2.1.5
This should give better debugging information (file names and line numbers) in the exception. 🤞
I've received word that changing from using HTTP-01 to using DNS-01 should be just fine, i.e. there isn't some strange thing on Let's Encrypt that would prevent that.
If all else fails, I can try to add more logging to give visibility into what things are set to and what things look like. This should help shed more light.
@blastagator commented on GitHub (Oct 28, 2020):
I installed the new version but it doesn't look like much changed in the log when trying to update:
@alexreinert commented on GitHub (Jan 24, 2022):
Same issue here. Because of the logging in my DNS scripts I can see, that the scripts are not called.
For me, it seems like the (already expired) HTTP authorization of the current order will be reused and no new DNS authorization will be created.