AlternativeIdentifierRefs problems with ACME New Certificate

The AlternativeIdentifierRefs parameter is used by the New-ACMECertificate cmdlet in ACMESharp when you want Let’s encrypt to have an secondary domain in the same certificate as your primary alias.
This is handy because Let’s Encrypt doesn’t support wildcards. EDIT: Let’s Encrypt ACMEv2 endpoint DOES support wildcards, but the Powershell module as it stands does not use ACMEv2.

I was having an issue when trying to do this;

New-ACMECertificate : The given key was not present in the dictionary

This was because in the previous steps in my script, I was only validating my ownership of the first alias – not of the alternative domains. I need to validate all domains before a certificate will be issued.

Here’s some code snippets of what I ended up with;

WCF Configuration Pt1 : SSL and Windows Authentication

WCF isn’t the easiest beast to wrangle, and when looking to secure a WCF web service I usually do it in stages.
In this post and further posts in the next week, I’ll be securing a WCF web service with various endpoints with various different security requirements.  To start with I’m just going to secure it with Windows authentication and SSL.

It always seems to take a little fiddling to get to the first stage, published in IIS using SSL and Windows Authentication whilst still functioning.

Once IIS has been configured

  • Website created
  • Single HTTPS binding
  • SSL Settings (Require) (Ignore client certificates)

The next step is to get the webconfig to work over SSL and to use windows authentication.

And the endpoint config will look something like this;

So there you go, simple configuration to use enforce SSL and Windows Authentication in WCF.