SuppProtoCertCentre functionality seems all broken now

[ap2021 0]

Just Updated to the latest version and getting zillions of errors around SuppProtoCertCentre after this:

  { V8.57 certificate supplier protocol, determines which functions are used to get certificates }
    TSupplierProto = (SuppProtoNone, SuppProtoOwnCA, SuppProtoAcmeV2);    { V8.62 Acmev1 gone }
               //       SuppProtoCertCentre, SuppProtoServtas);         { V9.5 CertCentre gone, Servtas never supported }
 

It's referenced in a lot of places.

 

I was probably just unlucky enough to Update in between things, but just in case nobody noticed this, thought I'd report it here anyway...

[Angus Robertson 626]

Sorry, my fault, I updated the Types unit before the new X509Certs unit was ready, I'll revert it in SVN.  Meanwhile, just find the old V9.4 Types unit.

 

Angus

 

[ap2021 0]

Thanks, you have fixed it now.

 

I was actually looking at CreateSelfSignCertEx in the context of HttpSys SSL certificate automation. What is the correct/best sequence of functions to call, to create a 10 year self-signed cert, import it into Windows, obtain its fingerprint and create a reservation + SSL binding? - I want my server to do this once, up-front at installation time.

 

I.e.: CreateSelfSignCertEx creates a PEM, plus it sets expiry to 2000 days, so it's probably already a wrong start. Then PEM cannot probably be directly imported into Windows store, it probably needs to be converted to PFX, or something, if I'm not mistaken. Then I'm not sure if you have a special function for reservations? And a function for the SSL binding? - and that last probably needs a fingerprint, so there should be another function that can give me that.

 

Any guidance would be appreciated. Likely, I'm not the first one to want this...

 

Another thing I would probably want is to also issue an SSL Client certificate as part of this process, signed by that self-signed cert above (if that makes sense; I suspect that for this, I would instead need to create a self-signed CA, then issue and sign both server SSL cert & client cert). This is to be able to authenticate my client, as an extra/2FA step. - I may be confusing terms, please correct me if I'm wrong. And I'll need guidance on which functions to call in what order for this as well, please. I believe that I should be able to use a single Client Cert like this on any number of client machines, I would not care what names they are, I just want to make sure these are "ours", as a preliminary check, before doing actual proper authentication later on - that would at least filter out any bots.

 

Maybe these two use cases are common enough to warrant separate "Easy" functions in ICS?

Edited 3 hours ago by ap2021

[Angus Robertson 626]

There is an ICS component TMsCertTools that can be used to create self signed cerrtificates, or create certificates signed by a CA root certificate, or read any certificate, and it has methods LoadOneFromStore and SaveToStorePfx that read and write to the Windows Certificate Store, optionally with private keys and intermediates.  Look at PemTools sample which uses it extensively.  So you can create your own CreateSelfSignCertEx using TMsCertTools instead of TSslCertTools that will install into the Windows Certificate Store. 

 

By certificate fingerprint, you probably mean the Sha1Hex or Sha256Hex of the DER X509 content, and those are methods for TX509Baae/etc.

 

However, ICS does not currently have any means to access IIS Site Bindings to associate certificates with IP addresses and ports.  I believe there are COM object methods that handle that, but not Windows APIs.  I do it manually every two months for my new Let's Encrypt certificates. 

 

For your client certificates, you should create your own CA root certificate using PemTool (tick Root Certificate Authority), similar to the ICS CA root, and maybe intermediate CA as well (as ICS does) since Windows does not always like end user certificates directly signed by a root, then CreateSelfSignCertEx will create your client certificates. 

 

Beware browsers nowadays don't usually use the Windows Store, and will sometimes also complain about manually added CA certificates, since these are commonly used by AV companies (and hackers) to intercept SSL communications, Edge currently complains about the ICS root CA, unless I've missed something.

 

Angus