Announcing release v0.8.0.0

[ACMESharp]

I'm pleased to announce the release of v0.8.0 of the ACMESharp client library and PowerShell module.

BREAKING CHANGES!

Please note, this release includes a major overhaul to many internals including persisted data structures.  For this reason many elements of this release are not backward compatible with your existing installations.  It is recommend that you create a new Vault and regenerate all of your Registrations, Identifiers and Certificates -- fortunately, there is little to no penalty for doing this against the Let's Encrypt servers since their service is free.

Downloading

You can get the components of this release in a few different forms:

• Release Archives
• NuGet Package - for developers
• Choco Package - for end-users

Highlights

Some of the bullets for this release:

• Vault Providers & Profiles - The Vault provider model has been completely revamped with the introduction of Vault Profiles.  For most users, you won't have to worry too much about this as the default Vault Profiles will automatically be used if you do not override them.  One important thing to note that is a breaking change with past behavior -- Vaults are no longer rooted at the current working directory path.  I know this was a source of a lot of confusion for some users in the past.  With this change, the default Vault Profiles use fixed, well-defined paths that are either user-specific or system-wide.  Custom Vault Profiles require users to explicitly define the Vault root path.  More details about the changes in the Vault Provider and Profiles model can be found here.

• Providers and Extension Points - ACMESharp internals use the concept of Providers to implement an extension mechanism for various key functions in its inner workings.  Prior to this release, there was a lot of inconsistency and many areas worked a little differently.  With this release, most of that has been corrected, and now most extension points use the same conceptual and implementation model (the remainder will be corrected in a future release; for those that are interested in the technical details, take a look at this.)  The following areas define extension points in the ACMESharp internals that leverage this change now or will in the future:
• Vaults - in addition to adopting the Provider model, Vaults are now externalized from the POSH module and can be used independently
• Challenge Types - as defined by the ACME spec, DNS and HTTP support is included, with TLS-SNI coming soon; new types defined in the future by the ACME spec as well as custom types can now be added very quickly and easily
• Challenge Handlers - as before the manual Challenge Handlers for DNS and HTTP come right out of the box; both the existing AWS S3 (awsS3) and Route 53 (awsRoute53) Providers, as well as the new IIS (iis) Provider, offer drop-in support for HTTP and DNS Challenge Handlers using their respective tools and services.
• Installers - coming soon, Providers that allow you to install certificates to IIS, AWS (ELB, CF, IAM, etc.) and Azure; additional Installers will be considered based on requests and submissions; this release does not include any native Installers yet, but the prior PowerShell Installer cmdlets are still included for now.
• PKI Handlers - coming soon, the PKI infrastructure was not touched in this release, but will be updated soon after to conform 100% with the new Provider model (it's about 80% compliant already).

• DNS Challenges are back! - When ACMESharp first launched it included support for both HTTP and DNS Challenge types, however the ACME specification later revised the details of the DNS Challenge type in an incompatible way and the Let's Encrypt project pulled support from their servers until they could be made compliant.  Well LE has reinstated support for DNS Challenges in their STAGING server, and will pby also be included in their BETA/PROD server by the time you read this.  ACMESharp's support for DNS Challenges has been verified as compatible with the LE servers.  DNS Challenges are a great alternative to HTTP Challenges because they don't require any changes to the Web server configuration or content.  As a reminder, out of the box the ACMESharp project supports a manual DNS Challenge Handler which gives you instructions on how to update a DNS record, or you can use the AWS Route 53 Challenge Handler provider which is available as an extension.

• PowerShell Module Updates - The PowerShell module has seen many updates in this release, including:
• The PS module has been renamed from ACMEPowerShell to ACMESharp.
• The cmdlets that make up the PS Module in ACMESharp have been updated to conform with the changes to the library internals and API interfaces.  Some cmdlets have gone away and been replaced with completely new ones, while others have just had their parameters updated.
• Many of the cmdlets now feature integrated help in the form of PowerShell Help which is accessible via the CLI or ISE -- the help is not yet completed for all the cmdlets, but it will be chipped away in subsequent releases until it is complete and comprehensive.
  
• ProviderConfigs are gone!  The concept of Provider Configs was not very user-friendly or script/automation-friendly with its method of generating JSON config files and launching editors (Notepad).  The related cmdlets are gone and are now replaced with cmdlets that let you discover and describe which Challenge Handlers are available.  Now you can simply specify parameters inline when completing a Challenge.  Optionally, you can define a Challenge Handler Profile if you want to define and reuse a combination of parameters in advance for a given Challenge Handler -- this gives you same power you had with Provider Configs, yet better flexibility and simplicity when you need it.  More detailed documentation for this change can be found here, but please note, this documentation is still very much WIP and still lacks a lot of detail.
• Automated testing has been put in place for the PS module (thanks to the generous service of powershell.org) to help detect issues quickly, this will help ensure our PS module support is stable and current going forward.  Additionally, we've been able to confirm compatibility for ACMESharp in different environments and establish our versions requirements baseline:
• ACMESharp supports:
• Windows:  2008R2, 2012, 2012R2
• .NET Framework:  4.5, 4.5.1, 4.5.2, 4.6 (5.x is planned but not currently supported)
• PowerShell/WMF:  v3, v4, v5

• Chocolatey Package - ACMESharp has already supported distribution of the library and extensions using nuget for developers and this is in use for a few dependent projects that I know about.  Now, ACMESharp improves its support for end-users with a Chocolatey package for the PowerShell module.  This is pby the easiest way to get started with ACMESharp for most folks, as it will install the module and make it automatically accessible in any PowerShell session.  This initial version includes the core ACMESharp module as well as all the official extensions in a single bundle.  In the future we may break it out into different packages so you can control what gets installed with more granularity based on user feedback.