Investigate "stateless" approach #46
Comments
|
I see the problem, that this is kind of an successor to ACMESharp, but the focus is a little bit different indeed. The ACMESharp module has not been stateless, but it hid away the state from you, by managing it in the background in a fully automatic fashion. IIRC it also was able to manage IIS-Sites automatically and such. About the scope of the module: If there are possibilities to make the module more beginner friendly and/or usefull, I'm all ears, Oh and btw:
|
|
Thanks for the quick response Thomas.
Naturally, everyone has his or her own style. My style includes a preference
for flexibility. Its seems from your response (eg. "let the specifics to the
user / administrator / script implementer") that flexibility would appear to
be your goal as well.
That said, I don't really understand why you would save some state to disk
but not all of it. That choice makes the tool less flexible. You could have
chosen the "all state to disk" approach (which is what I really meant and
why I used quotes: "stateless") and still allowed the movement of the same
data into and out of in-memory variables. If you had, the result would be
exactly the same as the current implementation (ie. current single-session
tool users would see no difference) PLUS the various register / order / auth
commands could all be run in a single session or each could be run
separately in multiple independent sessions, whichever the tool user
prefers.
IMHO, that's flexibility having little to do with hiding complexity (it's
not pandering to beginners either).
…-----Original Message-----
From: Thomas Glatzer [mailto:notifications@github.com]
Sent: Monday, November 25, 2019 11:35 AM
To: PKISharp/ACMESharpCore-PowerShell
Cc: George Schiro; Mention
Subject: Re: [PKISharp/ACMESharpCore-PowerShell] Investigate stateless
approach (#46)
I see the problem, that this is kind of an successor to ACMESharp, but the
focus is a little bit different indeed. The ACMESharp module has not been
stateless, but it hid away the state from you, by managing it in the
background in a fully automatic fashion. IIRC it also was able to manage
IIS-Sites automatically and such.
While such an approach hides some of the complexity, it'll make it difficult
to reach into the process and get intermediate results. The approach here is
more to provide a protocol handler, and let the specifics to the user /
administrator / script implementer, e.g. I'll provide you with everything
neccessary to fulfill the AuthZ, but you know your environment the best and
just need some lines of PS to put the challange-files where they need to be
or to modify your DNS.
About the scope of the module:
The hard part of ACME is to have something speaking the protocol and
correctly answering the authorizations. The module will help with the
protocol and provide the means to answer the authorization. It tries not to
assume your environment and thus, it's made to be used in your scripts - not
to replace them.
If there are possibilities to make the module more beginner friendly and/or
usefull, I'm all ears,
Also I understand, that migrating from ACMESharp might be steep. Perhaps I -
or we? - can provide guidance how to migrate from common scenarios.
Oh and btw:
a.. It's Thomas ;)
b.. I don't feel "piled", but the message from #44, which you also cited
seemed borderline pushing / demanding.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
glatzert
changed the title
|
Essentially every command until certificate key generation and exporting the completed certificate will use the State-Object and will be able to make use of it. What do you think are other actionable items? |
|
I would avoid automatic updates, but I would also suggest some new syntax.
Old syntax:
$order | Update-ACMEOrder $state -PassThru;
New syntax (to be available in addition to the "old" syntax):
Update-ACMEOrder -Path "path to ACME working folder";
where "-Path" has the same meaning as it does for "New-ACMEState" and
"Get-ACMEState".
"single-line-initialization for the state, using some default path"
You already have state initialization with "New-ACMEState". In my
experience, a default path will only make it harder for newbies to find the
state stuff on the disk (everyone wants to browse through it). I wouldn't
use it.
The tool already works great as is (excepting multi-session support). All
that's really needed, IMHO, is making the passing of the various in-memory
objects optional. Here's the entire set of proposed new syntax:
New-ACMEState -Path "path to ACME working folder";
Get-ACMEServiceDirectory -Path "path to ACME working folder" -ServiceName
"ACME service name"
New-ACMENonce -Path "path to ACME working folder";
New-ACMEAccountKey -Path "path to ACME working folder";
New-ACMEAccount -Path "path to ACME working folder";
New-ACMEOrder -Path "path to ACME working folder" -Identifiers
$identifiers;
Get-ACMEAuthorization -Path "path to ACME working folder";
beg loop thru SAN names
Get-ACMEChallenge -Path "path to ACME working folder" -Identifier
$identifier -Type "http-01";
Complete-ACMEChallenge -Path "path to ACME working folder" -Identifier
$identifier;
end loop thru SAN names
Update-ACMEOrder -Path "path to ACME working folder";
New-ACMECertificateKey -Path "path to ACME working folder";
Complete-ACMEOrder -Path "path to ACME working folder";
Update-ACMEOrder -Path "path to ACME working folder";
Export-ACMECertificate -Path "path to ACME working folder" -ExportPath
"{CertificatePathFile}";
Note: "* loop thru SAN names" is not part of the proposed new syntax, it
just shows where SAN activity happens.
I suggest that the only new "automatic" behavior should perhaps be the
calling of "New-ACMECertificateKey" from within "Complete-ACMEOrder" (if the
key doesn't already exist in the state object).
FYI, I think there was a question some time ago about SAN support. I've
confirmed that the code already supports a SAN list - and it works
perfectly.
…-----Original Message-----
From: Thomas Glatzer [mailto:notifications@github.com]
Sent: Monday, November 25, 2019 2:31 PM
To: PKISharp/ACMESharpCore-PowerShell
Cc: George Schiro; Mention
Subject: Re: [PKISharp/ACMESharpCore-PowerShell] Investigate "stateless"
approach (#46)
Essentially every command until certificate key generation and exporting the
completed certificate will use the State-Object and will be able to make use
of it.
That's probably something which could be added, so the CertKey will be
stored along the order - probably removing a pain point for
"multi-session"-users.
Also an automatic update of the order from HDD might be feasable - same for
other objects like account-key (which is most likely not needed to be
updated frequently).
The state itself could be made automatically available to running cmdlets by
leveraging the $PSDefaultParameterValue-Hashset (at least as an opt-in).
On top of that, there could be a single-line-initialization for the state,
using some default path as well as a default-path for the state.
What do you think are other actionable items?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
So - to allow this the following has to happen:
I don't see any donwsides to this approach currently. |
|
I know that's a lot to think about (let alone do). To obviate the need for always having to use a single session, an alternate syntax for every command would be the ideal. But perhaps there is an intermediate step that would serve the same purpose. Consider defining 4 new commands to write state to disk: Plus 4 corresponding commands to read state back from disk: Does that make more sense Thomas? Would that cover all multi-session scenarios? |
|
Hi George, I'd always use PowerShell allows to define ParameterSets, which allows to disambiguate between different modes of CmdLets, thus I'll probably define "overloads" of the given commands which accept will accept either To make all that "multi-session" enabled, the State-Object itself needs to read everything on demand instead of reading on creation and thus will need some changes (especially regarding the order objects). This is especially true for concurrent multi-sessions. But I don't like to have surprises, if users (for whatever reason) switch between multiple sessions more or less simultaneously. So the first thing I'll be doing is making the State not doing everything in Memory, but directly interacting with the underlying storage - especially for loading. |
|
I started workin on it - but it'll probably take some time. If that's finished, I'll look into storing the certificate-key alongside the order. |
|
Please let me know if there is anything I can do to help test or anything
else.
Thank you for taking this request seriously Thomas. Your efforts are greatly
appreciated.
…-----Original Message-----
From: Thomas Glatzer [mailto:notifications@github.com]
Sent: Monday, December 02, 2019 5:49 AM
To: PKISharp/ACMESharpCore-PowerShell
Cc: George Schiro; Mention
Subject: Re: [PKISharp/ACMESharpCore-PowerShell] Investigate "stateless"
approach (#46)
I started workin on it - but it'll probably take some time.
I began with splitting the AcmeState Object into multiple ones, all
implementing the same "interface" making the code simpler for in-memory
state vs persisted state. The latter one will always load from disk and not
store anything in memory.
If that's finished, I'll look into storing the certificate-key alongside the
order.
When that's done, it'll be fairly simple to enhance all cmdlets to allow
getting a statepath instead of a state.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Happy New Year Thomas! I've been wondering if there has been anything new on this topic. I noticed a new branch named "deep-state" (cute). Any bearing? |
|
Essentially its done in the aforementioned branch - except one thing: I have yet to reach out to StackOverflow and/or the PowerShell-Gurus, I know to get that figured out. Happy new year. |
|
Fantastic! Is "deep-state" at a point I can test? Or do you need to resolve the "-State Parameter" issue first? |
|
The last state I commited, should be usable, if you use Get-AcmeState as before. |
|
Ah sorry - the automatic certificate key management is missing - I forgot about that. |
|
Ok, I will check in later. Thanks Thomas! |
|
The State parameter will now accept strings. |
|
I'll push the current changes to the gallery and close this issue after that. |
|
It looks like "1.1.3-beta" in the gallery is what I should be testing. Please correct me if I mistaken in this Thomas. This is what I did with version "1.1.0": Perhaps I am missing something basic with usage. Here's what I see with a preliminary test: That looks fine (I think). Here's where I get an exception: My guess is a problem with the new "StringToAcmeStateConverter" class or I just don't yet understand how to use it. |
|
Hm. I tested with "New-Nonce" and it went through fine.
Which PS-Version are you using?
Am 19.01.2020 23:31 schrieb George Schiro <notifications@github.com>:
It looks like "1.1.3-beta" in the gallery is what I should be testing. Please correct me if I mistaken in this Thomas.
This is what I did with version "1.1.0":
$state = New-ACMEState -Path "C:\Users\admin\Desktop\tmp\AcmeState"
Get-ACMEServiceDirectory $state -ServiceName "LetsEncrypt" -PassThru
Perhaps I am missing something basic with usage. Here's what I see with a preliminary test:
New-ACMEState -Path "C:\Users\admin\Desktop\tmp\AcmeState"
AcmeDiskPersistedState
That looks fine (I think). Here's where I get an exception:
Get-ACMEServiceDirectory "C:\Users\admin\Desktop\tmp\AcmeState" -ServiceName "LetsEncrypt" -PassThru
Get-ACMEServiceDirectory : Cannot process argument transformation on parameter 'State'. Cannot convert the "C:\Users\admin\Desktop\tmp\AcmeState" value of type "System.String" to type "AcmeState".
At line:1 char:26
+ ... t-ACMEServiceDirectory "C:\Users\admin\Desktop\tmp\AcmeState" -Servic ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [Get-ACMEServiceDirectory], ParameterBindingArgumentTransformationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Get-ACMEServiceDirectory
My guess is a problem with the new "StringToAcmeStateConverter" class or I just don't yet understand how to use it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#46>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACNPDCG6KR4XHQCAUUIO25DQ6TIERANCNFSM4JRLDQ7A>.
|
|
$PSVersionTable.PSVersion I manually downloaded, extracted and copied the "1.1.03-beta" files myself. Here's the file list: That shouldn't make any difference, right? |
|
No it should not - at least not to my knowledge. My build version differs ... But I'll take a look into the module code again, before jumping into that rabbid hole ... |
|
I ran everything on a Azure Machine, and it works fine. Are you positive you loaded (or imported) the new module version? You can check that by running |
|
Get-Module ACME-PS |
|
Sorry Thomas, here's what I get when I try the typical install (1.1.3-beta instructions): Install-Module -Name ACME-PS -AllowPrerelease |
|
If it does not know -AllowPrerelease, you need to Install and then Update some Modules around PowershellGet. |
|
This might also be true for the ACME-PS Module - If you loaded an older one and the new one, IPMO might have done nothing, since there was already a version of the module |
|
BTW Get-Module will report 1.1.3, since it can't handle Prereleases. |
|
I did a package & get update: Using the same manually downloaded, extracted and copied "1.1.03-beta" files I tested yesterday, I see this: New-ACMEState -Path "C:\Users\admin\Desktop\tmp\AcmeState" Get-ACMEServiceDirectory "C:\Users\admin\Desktop\tmp\AcmeState" -ServiceName "LetsEncrypt" -PassThru It's working now. Thank you for your patience Thomas. I will proceed with full testing soon. |
|
I know we can reconstitute an authorization (BTW, you have "Authroization" as one of the synopsis bullets in "README.md") from an existing order like this: It's not clear to me how to reconstitute an order. What we've done previously is this (with $state in place of the path string): But this requires "$order" to kept in memory for later use. I tried this: But this fails on a missing "Url" argument (a value we would not know). So the question remains, how do we reconstitute an order knowing just the state path? |
|
After reviewing a successful SAN submission with several names (done via 1.1.0 code), I noticed everything is handled in what appears to be a single order (eg. one "Order-GLC_pFUkUY6z8QXOYx7acYGmX_I0lHycNcek68aprcg.xml" file with all SANs listed). This means we only ever have one order to be concerned with. Thomas, is there a way (currently) to "get the first order" or "get the only order out there"? |
|
There's $state.FindOrder() to find an order by DNS names.
I'll expose that via a new cmdlet or a variant of get-order. Noticed it as well, when I tested the beta.
1.1.0 code means, I did not break anything in the new beta?
Am 23.01.2020 21:10 schrieb George Schiro <notifications@github.com>:
After reviewing a successful SAN submission with several names (done via 1.1.0 code), I noticed everything is handled in what appears to be a single order (eg. one "Order-GLC_pFUkUY6z8QXOYx7acYGmX_I0lHycNcek68aprcg.xml" file with all SANs listed).
This means we only ever have one order to be concerned with.
Thomas, is there a way (currently) to "get the first order" or "get the only order out there"?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#46>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACNPDCD5TUXKKWKOY3AOKH3Q7H2SNANCNFSM4JRLDQ7A>.
|
|
"1.1.0 code means, I did not break anything in the new beta?" We haven't completed our testing, so can't say yet what may or may not be broken in the beta. "1.1.0 code" meant I looked at "AcmeState" for a process we have still running the 1.1.0 code. |
|
The 1.1.0 code should also support the $state.FindOrder(). It takes an array of DNS names to find the best matching order in the state |
|
1.1.3-beta2 now comes with Find-Order |
|
This should all work in 1.1.3-beta3, so I'm closing the issue. |
First, I don't mean to pile on because I think the work you've done here is terrific Tom. Thank you for making such a valuable contribution to the developer community. And please let me know if my next comments would be more appropriate elsewhere.
I have seen the same issue reported by Slamich and I independently arrived at the same solution (ie. "openssl.exe"). I am fine with leaving it at that.
"The fact is that there were no such problems with the previous ASMESharp module."
This is my real concern.
I am sure there are many others who migrated to "ACME-PS" from "ASMESharp" (who are also very grateful for your efforts Tom). With that migration in mind I have been wondering about something else.
One nice feature of "ASMESharp" was its "stateless" implementation (ie. it saved 100% of its own state to disk). That approach allowed its various commands to be run independently in multiple (ie. separate) Powershell sessions (one after another) without concern for losing state.
"ACME-PS" does not allow this. While "ACME-PS" saves some of its state to disk, the balance requires the use of temporary in-memory PS variables. That means users must complete the entire process in a single Powershell session.
Can you please explain that design choice Tom? Is there an easy way to arrive at a similar "stateless" approach (ie. similar to how "ASMESharp" manages 100% of its own state itself) ?
Originally posted by @GeorgeSchiro in #45 (comment)
The text was updated successfully, but these errors were encountered: