Implement certificate revocation

[pkisharp]

Implement certificate revocation

[ebekker]

Thanks for the praise.

I'll try to get this implemented in the next couple of days.

[WouterTinus]

I've just submitted a PR to help out. You may want to refine it a bit more but the basics are working: #15

[WouterTinus]

Hi Eugene, do you think you will have some time to look at this anytime soon? I don't want to release WACS 2.0 without this feature, otherwise I'd not be able to something that 1.9 could.

[ebekker]

As soon as AV build successfully, I'll publish to nuget, thanks for the contributions!

[WouterTinus]

Thanks for the merges! Looking forward to seeing it on the feed.

[ebekker]

After reviewing your other PRs, they all looked good to me and I merged them in, but afterwards realized in one of the PRs you reverted the Revoke support, any particular reason why?

[WouterTinus]

That's my lack of experience with Git branches I'm afraid. I started working from the master branch but then after revoke support was done I figured I should submit the PR from a feature branch before continuing with the next change.

Then the next feature branch I created also had the Revoke code in, and I figured that you should be able to merge the features independently, so I reverted the Revoke part from that branch. I guess that is what's messing up the merges now. Sorry for the mess!

[ebekker]

No problem, I still consider myself a Git newbie as well :-)

Why don't we do this. I want to make sure that you get full attribution for the revoke feature. I've reviewed and merged in all the outstanding PRs (yours and others) so the code is now updated with everything. I believe (hope) the revoke feature was the only thing that was lost.

Can you submit a new PR against the latest from master with the revoke features back in place? I'll pull those in, and once the build completes, I should be able to build a new release and unblock your 2.0 release.

[WouterTinus]

The new PR is ready!

[ebekker]

OK, took a little longer than I thought. I noticed the build was not working correctly in Appveyor and decided to get it running in ADO to help track down the problems. Took a little detour, but it was worth it, I was able to clean up a number of outstanding unit/integration test issues.

I also added some additional tests to exercise the Revoke operation against LE STAGE in the integration tests, which confirmed it's working, and also implement the mock operation in the local Mock server.

Anyway, after the good results from the improved and verified tests, I think I'm satisfied to take off the BETA label, so just built and pushed to nuget, what I'm considering the first RTW release, v2.0.1.105.

Give it a shot and hopefully no problems integrating with win-acme.

Thanks for all your help!

[WouterTinus]

That's great news! The first release of WACS 2.0 will follow soon. If you fixed the tests for AV, that might mean that I can run them too. You might see some follow ups for #13 and #14 soon then :)

[ebekker]

So the integration tests work on my local environment, in AV and in ADO. But the way they work is that I use some AWS services (Route 53 and S3) to support the handling for DNS and HTTP challenges.

So, if you want the integration tests to run in your local environment, then you need to setup a couple things. First thing, you need to create a local AWS credential profile named acmesharp-tests configured with an AccessKey and SecretKey for your AWS account.

Next, you need to create a couple configuration files for the AWS service helper classes (there's a class for Route 53 and a class for S3).

You want to place them under the subdirectory config/_IGNORE under the root of the IntegrationTest project. You will find templates for each config file checked into the config subdirectory.

You can copy those files and edit them to replace the embedded variable values. But rename them to be:

• R53Helper.json
• S3Helper.json

Now, the last thing you'll need to do is make a local modification to one of the tests source files here and here. Right now the integration tests are hard-coded to use a fixed set of DNS subdomains and to get the tests to work for you, you'll need to edit them to match a DNS subdomain that you have control over and whose DNS nameservers are registered with your AWS Route 53 service.

It's a little bit complicated, but once you have that setup, you should be able to see the integration tests work for you.