mirror of
https://github.com/ridercz/AutoACME.git
synced 2026-04-25 15:15:53 +03:00
[GH-ISSUE #24] Full certificate chain in export #22
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/AutoACME#22
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 @Ich79 on GitHub (May 18, 2018).
Original GitHub issue: https://github.com/ridercz/AutoACME/issues/24
Hey!
I am using autoACME and we're very happy with it for IIS. We also have a mailserver (hMailserver to be precise) and I would also like to use the let's encrypt certificate for that.
Unfortunately the certificate is missing the full chain which makes it much harder to use the certificates on for other services.
Maybe it's enough to make AcmeContext.cs:98 configurable. In the end hMailserver requires the certificate as a textfile, not PFX but maybe it works.
Is this something which you might consider? Like a parameter e.g. fullchain=true?
Even if not, thanks a lot for this piece of software!
Best regards,
Boris
@Ich79 commented on GitHub (May 19, 2018):
Just to be sure: I mean full chain in the PEM file, not PFX ;)
@ridercz commented on GitHub (May 19, 2018):
First of all: Why would hMailServer need full chain? I use it as well, without full chain and without any problems. LE certificates have correct Authority Info Access, so client can build their chain without any problems.
Second, I can probably add it in future version, why not.
@Ich79 commented on GitHub (May 21, 2018):
Hi!
Oh ok, I tried it once with the certificate provided by autoACME and had issues with https://www.checktls.com/ as the full chain was not provided by the server.
Maybe it messed something up. If so, sorry for the issue opened!
Thanks!
Boris
@eleasarchriso commented on GitHub (Sep 14, 2018):
@ridercz - can you please provide the steps you take for using the certificates in hmailserver? With win-acme I got a chain/key pem file that I was able to use.
@avonwyss commented on GitHub (Sep 14, 2018):
@eleasarchriso AutoACME generates PFX files, You can use OpenSSL on the command line (and thus also script that) to split these up into their parts (e.g. PEM and PVK files), see for instance https://support.comodo.com/index.php?/comodo/Knowledgebase/Article/View/548/7/
@eleasarchriso commented on GitHub (Sep 17, 2018):
Ok thanks. Yes this is what I am doing now. I thought there might be some setting/option in AutoAcme that I was missing like the PEM folder in the configs.
Is there any option to run some script after a new certificate was downloaded where I could plug in this generation of the hmailserver certificates?
@avonwyss commented on GitHub (Sep 17, 2018):
@eleasarchriso No, I'm not aware of such a feature, but you could open a request for that: Pre- and post-request scripts could maybe be added to the certificate host information, so that only specific certificates would trigger these actions.
@Ich79 commented on GitHub (Feb 22, 2019):
Hi!
I was just playing around with it. Most software (e.g. Joomla, MX Toolbox, luxsci) apparently will not consider the certificate trustworthy, if the server is not sending the full chain. Currently hMailserver is using the PEM and CRT file, that are created during issuing process (completely ignoring the PFX file) as is.
Any plans on exporting the full chain into the CRT file? That might fix this issue. It does work, if I copy the contents manually into the file..
Thanks,
Boris
@avonwyss commented on GitHub (Feb 22, 2019):
@Ich79 I assume that when you say "the full chain" you mean the chain up to (but excluding) the root CA, right? E.g. the domain cert and the intermediate cert, but not the root cert.
@ridercz commented on GitHub (Feb 23, 2019):
Added in 1.6.1.