I'm pretty sure this isn't possible, but maybe someone understands Windows better.

Windows provides a means no bind a certificate to a port using netsh.exe. This means (at least for standard Windows networking calls) connections to that port will be given the bound cert.

The Vibe.d documents state that a Certificate chain and key needs to be provided. I'm pretty sure that the port binding requires very specific Network API calls, possible .NET only. Can any confirm or deny?

On 03/10/2017 4:52 PM, Jesse Phillips wrote:
> I'm pretty sure this isn't possible, but maybe someone understands Windows better.
> 
> Windows provides a means no bind a certificate to a port using netsh.exe. This means (at least for standard Windows networking calls) connections to that port will be given the bound cert.
> 
> The Vibe.d documents state that a Certificate chain and key needs to be provided. I'm pretty sure that the port binding requires very specific Network API calls, possible .NET only. Can any confirm or deny?

Perhaps you could reference the command (aka the args with an example)?
Otherwise, its a lot harder to figure out what it is doing under the hood.

On Tuesday, 3 October 2017 at 23:29:49 UTC, rikki cattermole wrote:
> On 03/10/2017 4:52 PM, Jesse Phillips wrote:
>> I'm pretty sure this isn't possible, but maybe someone understands Windows better.
>> 
>> Windows provides a means no bind a certificate to a port using netsh.exe. This means (at least for standard Windows networking calls) connections to that port will be given the bound cert.
>> 
>> The Vibe.d documents state that a Certificate chain and key needs to be provided. I'm pretty sure that the port binding requires very specific Network API calls, possible .NET only. Can any confirm or deny?
>
> Perhaps you could reference the command (aka the args with an example)?
> Otherwise, its a lot harder to figure out what it is doing under the hood.

Here is the command docs

https://msdn.microsoft.com/en-us/library/windows/desktop/cc307220(v=vs.85).aspx

On 04/10/2017 3:54 AM, Jesse Phillips wrote:
> On Tuesday, 3 October 2017 at 23:29:49 UTC, rikki cattermole wrote:
>> On 03/10/2017 4:52 PM, Jesse Phillips wrote:
>>> I'm pretty sure this isn't possible, but maybe someone understands Windows better.
>>>
>>> Windows provides a means no bind a certificate to a port using netsh.exe. This means (at least for standard Windows networking calls) connections to that port will be given the bound cert.
>>>
>>> The Vibe.d documents state that a Certificate chain and key needs to be provided. I'm pretty sure that the port binding requires very specific Network API calls, possible .NET only. Can any confirm or deny?
>>
>> Perhaps you could reference the command (aka the args with an example)?
>> Otherwise, its a lot harder to figure out what it is doing under the hood.
> 
> Here is the command docs
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/cc307220(v=vs.85).aspx 
> 

"Application program source files include the Http.h header file to access function prototypes and structure definitions for the HTTP Server API. Developers can use the Httpapi.lib library file to build applications that use the HTTP Server API. At runtime, applications link to the Httpapi.dll."

So no, vibe.d can't work with it. This a special snow flake feature from 2k3 server days.

On Wednesday, 4 October 2017 at 03:39:22 UTC, rikki cattermole wrote:
> On 04/10/2017 3:54 AM, Jesse Phillips wrote:
>> https://msdn.microsoft.com/en-us/library/windows/desktop/cc307220(v=vs.85).aspx
>> 
>
> "Application program source files include the Http.h header file to access function prototypes and structure definitions for the HTTP Server API. Developers can use the Httpapi.lib library file to build applications that use the HTTP Server API. At runtime, applications link to the Httpapi.dll."
>
> So no, vibe.d can't work with it. This a special snow flake feature from 2k3 server days.

Thank you, and it looks like core.sys.windows doesn't have this header file defined either.

And now I've learned something new about MSDN docs.