ap2021

Ok, thanks, I think I have figured it all out, just polishing it with exception handling, logging and testing...

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?

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...

Fair enough, still a shame to see a good advise go to waste...

Angus, Just wanted to add that fundamentally, sometimes you need to process actual text strings (ANSI or not) and sometimes binary data and it would be nice if this distinction was immediately obvious. It's a universal semantical headache, and C++ has the same problem, because there are just so many data types available and they may all look the same and essentially do the same thing. For example in OpenSSL, there are such function declarations: int EVP_DigestVerifyInit_ex(EVP_MD_CTX *ctx, EVP_PKEY_CTX **pctx, const char *mdname, OSSL_LIB_CTX *libctx, const char *props, EVP_PKEY *pkey, const OSSL_PARAM params[]); Here, mdname is semantically a string. So it can be / actually is 0-terminated and with no size needed separately, hence pansichar is the correct type we should use in translated Pascal definitions. Unless we know for a fact that the target function expects and can handle Unicode text in UTF8, then we must use putf8char datatype in the tarnslated definitions, or it would cause problems, unless additionally typecast. But here: int EVP_DigestSignUpdate(EVP_MD_CTX *ctx, const void *data, size_t dsize); The data parameter is semantically binary data - they are trying to convery this by using the word "data", there's also a requirement to pass in the size separately and they are trying to use a different data type for it, not just "const char *" (which it could have been, interchangeably), but "const void *". Sometimes, in exactly same way, they may use "const unsigned char *" type instead, but that's because they are just as confused about it as we are in Delphi: __owur int EVP_DigestVerify(EVP_MD_CTX *ctx, const unsigned char *sigret, size_t siglen, const unsigned char *tbs, size_t tbslen); In fact they may have interchangeably used "const char *" for the same data in odd places, because apart from the semantics, it would achieve the same result and if the original developer was tired or lazy, the type used may not reflect its semantical significance. Besides, C++ has no special data type for binary data, so this issue has no silver bullet solution in C++. This confusion then spills over into all other languages and then you translate it in your code, without regard to semantics, as: EVP_DigestVerify : function(ctx: PEVP_MD_CTX; sigret: PAnsiChar; siglen: size_t; tbsret: PAnsiChar; tbslen: size_t): Integer; cdecl = Nil; { V8.52, V8.64 corrected declaration } using PAnsiChar type. This may have been acceptable in Delphi 1 days, but today we have a better data type we should use instead: TBytes. You do not want sematics to be lost in translation, although the original semantics may need to be deduced first, because in C++ it may not be very clear. These functions should be declared in Delphi with TBytes type instead, i.e.: EVP_DigestVerify : function(ctx: PEVP_MD_CTX; sigret: TBytes; siglen: size_t; tbsret: TBytes; tbslen: size_t): Integer; cdecl = Nil; { A future version, properly corrected declaration } or EVP_DigestVerify : function(ctx: PEVP_MD_CTX; const sigret: TBytes; siglen: size_t; const tbsret: TBytes; tbslen: size_t): Integer; cdecl = Nil; { A future version, properly corrected declaration } Which is essentially the same for the operation of the function, but is semantically much clearer and 1) allows Delphi to enforce the type and avoid any internal conversions, 2) will directly accept TBytes parameters without resorting to very frequent PAnsiChar() typecasts and 3) will keep it much clearer to the user/coder. For instance, this will allow you to avoid weird conversions like these: function IcsAsymVerifyDigest(const Data, OldDigest: AnsiString; PublicKey: PEVP_PKEY; HashDigest: TEvpDigest = Digest_sha256): Boolean; begin Result := IcsAsymVerifyDigestTB(IcsStringAToTBytes(Data), IcsStringAToTBytes(OldDigest), PublicKey, HashDigest); end; And will allow you to get rid of AnsiString and AnsiChar parameters, at least the majority of them. With some thought before changes and some testing after, it would really clean up this mess. It cannot be blindly applied to any such translated datatype, each function will need to be looked at separately to figure out the underlying meaning of the type used. But again, perhaps it does not have to be applied to all declarations at once, you can start with a handful of these functions, either picking the ones that you use, or care about or those that may seem easier and then roll it out to others at will. Also, for Delphi, PAnsiChar literally refers to "0-terminated strings", which causes it to drop parts of data after the first #0 it encounters, when it's doing internal conversions, those we do not see and do not expect, therefore introducing hard to troubleshoot bugs. Does this make sense? Do you agree?

I guess an even easier fix would have been to define Smtp DefEncArray with pansichar in the first place. Angus, please add it to your list. I can confirm that Olli73's solution works.

Many thanks, that was indeed the solution! Wunderbar!

Just set the DefaultEncoding property to smtpEncBase64. The text is fine, it just gets BASE64-encoded and then never decoded by the mail client. TSslSmtpCli works with normal UTF16 strings and theres very little stuff going on outside of it, so there are no character conversions that I can see and none that I do, all text I tested so far was just plain English.

Oct 13, 2024 You should get rid of those ansistrings in all callable routines and do the conversions behind the scenes if you must.

Interestingly enough, this "fix" broke it for me under Windows. The fix for which, was to just use TB version. Ansistrings are unpredictable now, Delphi supports them reluctantly and there are probably unwarranted conversions going on under the hood, somewhere, using pansichar's.

Trying to send an email (through ICS), but getting it BASE64 encoded. The Content-Transfer-Encoding header on the message is set to just a single letter "b". Looks like the encoding is messed up somewhere, but it's all ICS vanilla code, all I do is call the SslSmtpCli object and have a callback to perform the steps. Also, I think it used to work for me before. Were there any breaking changes there recently? PS: Changing the DefaultEncoding to smtpEncQuotedPrintable, for instance, sets that header to "q" and the message contains some garbage.

Does ICS offer anything to create ISAPI modules or filters for IIS? MS warns that "HTTP.sys isn't compatible with the ASP.NET Core Module and can't be used with IIS or IIS Express.", therefore there may be compatibility issues there. In my scenario, I also intend to run this on a Plesk-managed server, which offers full remote management for IIS, as well as setting up free Let's Encrypt certificate and automatically renewing it every 3 months - this latter is my main reason to use this IIS setup and not http.sys. If I can reproduce it with ICS components, I will certainly try.

It's just convenient sometimes, that's all. PS: Manually removing multi-platform garbage from DPROJ files in Notepad has now become almost mandatory. I started doing that because a) all that did not make any sense there and b) it was wasting space, but now it's easy to see how that garbage is actually causing problems.

So am I, pirated it on floppies too. And you are just being rude. I have not only described this issue perfectly, I have also provided 3 easy reproducible test cases, 2 of which exhibit this issue and 1 does not. Anyway, it boiled down to the multi-platform garbage DataSnap wizard adds to the DPROJ. And _manually_ removing it, fixes this issue: after that, all ICS components become available. So while yes, it's a Delphi problem, you should document it on your side as well: without this knowledge, ICS is not easily usable in DataSnap or DLL projects. And it is a manual DPROJ editing task, there's no GUI for that in IDE. I should probably advertise a class on how to do that 😉

Angus, my test case is to create a new DLL project, add Data Module and try placing any ICS controls on it - very few show as available. There's something about Libraries that ICS does not like, it would seem. Is this what you would expect? Or anything you can change? The same happens with projects created by DataSnap WebBroker wizard (targeting Windows/IIS ISAPI). But remarkably, a Windows/ISAPI projects created by IntraWeb wizard do not have this issue: I can see and use all ICS components on any of the 3 modules/forms it creates. So, perhaps it's not the fact that it's a Library? It's got to be something else.