My experience with "Let's Encrypt"

[Wolfgang Orth]

Hello all,

yesterday I tinkered my first https-webserver and I want to share the experiences I made on that journey.

It started with a regular sever. I added all the usual controls, like Logging, Performance and that new one to fetch the certificate.

When I pressed that "Certificates"-button to fetch the certificates (Testing was on!) I got some responses, like the textfiles a/b/c.txt could not be created. They have something to do with the generating of the keys. Big mystery, but once you get it going, you do not have to care. Those a.txt, b.txt. c.txt contain the random generated values, on which base the encryption of the certificates are made.

During compile the IDE told me, that OpenSSL.EXE has not been found in the path, therefore it did not get copied. So I thought, this program is needed.

Based on my experience on making a self-signed web-certificate before with Nettalk 9, I searched for the most recent version of OpenSSL.EXE on my LAN and found one in an Apache. The most recent version, because the output of old versions of OpenSSL.EXE provided by SC and Capesoft are utilizing deprecated protocolls, like SSL.
Copied that one I found to my folder where the new server resides, but when I tried to fetch the certificates, OpenSSL.EXE issued an error-mesage, saying that VCruntime140.DLL was missing.

So I tried an older one. I picked the one I found in drive:\\Clarion10\accessory\bin, which was from 09. July 2015.

However, from issuing my own certificates in the past, I knew this will probably not work.

Pressed that "Certificates"-button again, now I got the message(s) that LIBEA32.DLL and SSLeay32.DLL are missing.

So I copied them, and <bam> the certificates all got created!

H_o_w_ever, when trying to reach my new certified server, FireFox tells me: SSL_ERROR_NO_CYPHER_OVERLAP.
Edge returns DLG_FLAGS_INVALID_CA, later also DLG_FLAGS_SEC_CERT_CN_INVALID.

Here happened what I mentioned before, that this OpenSSL.EXE creates either SSL or TLS 1.1 or whatever these old standardws were called. That was the reason why I tried a recent version. Tried that recent version with the date of 28.03.2018 again (which is not necessarily the compile date, more the date when I unzipped this Apache 2).
Okay, searching, wheteher I have this VCruntime140.DLL somewhere on my disk. And indeed, there was one. Its codesigned by Microsoft, so I thought its okay.

Now I re-fetched the certificates, ...... and I saw the communication between my server and the certificate issuer flowing in! Called the site with FF and <tataaa> got SEC_ERROR_UNKNOWN_ISSUER - because this is a testing-certificate. Right? Very probably, because the cert page info says "Validated by: CN=Fake LE Intermediate X1".

But it worked!

Details: Connection encrypted (TLS_ECDHE_RSA_WITH_AES_128_CGM_SHA256, 128-Bit-Key, TLS 1.2)

Well, the responses are in german, its all translated by me.

But, with jumping through some loops, it finally runs.....

Conclusion: We have to find a way to provide compatibility of the tools, so that not everyone has to repeat this frustrating process of try-and-error to find the correct tool du jour. Perhaps at least a list with the correct names and dates of the missing EXE/DLLs.

For now I keep this test-certificate, while continuing work on this server on my decvelopment machine, before I move it to the projected destination.

Thanks for reading and have a good start into the week
Wolfgang

[Bruce]

>> Conclusion: We have to find a way to provide compatibility of the tools, so that not everyone has to repeat this frustrating process of try-and-error to find the correct tool du jour. Perhaps at least a list with the correct names and dates of the missing EXE/DLLs.

I'm not sure why, but it seems like your NetTalk install did not work correctly, and that is the real root of your problem.

The nettalk install puts OpenSSL.Exe, and the required DLL's, into your \clarion10\accessory\bin folder.

When you do a compile these files are then copied to your application folder.

When you deploy you need to deploy the files as described here;
http://www.capesoft.com/docs/NetTalk10/NetTalk.htm#DeployingAtlsClientOrServer

The OpenSSL.Exe version we include in the install is currently dated May 25, 2017 (although it is updated from time to time.)
The 2 DLLs (LibCrypto and LibSSL) are version 1.0.0F.

I recommend you re-install NetTalk 10, and follow the trail above, to see where it goes wrong.

>> The most recent version, because the output of old versions of OpenSSL.EXE provided by SC and Capesoft are utilizing deprecated protocols, like SSL.

This is inaccurate.

>> Based on my experience on making a self-signed web-certificate before with Nettalk 9,

Given the changes between NetTalk 9 and NetTalk 10, your experience with certificates in NetTalk 9 is likely not useful, and should be considered irrelevant.

Cheers
Bruce

[Wolfgang Orth]

>> Conclusion: We have to find a way to provide compatibility of the tools, so that not everyone has to repeat this frustrating process of try-and-error to find the correct tool du jour. Perhaps at least a list with the correct names and dates of the missing EXE/DLLs.

I'm not sure why, but it seems like your NetTalk install did not work correctly, and that is the real root of your problem.

The nettalk install puts OpenSSL.Exe, and the required DLL's, into your \clarion10\accessory\bin folder.

I looked up that folder and can confirm, that OpenSSL.EXE and the two DLL sit there.

When you do a compile these files are then copied to your application folder.

OpenSSL.EXE was not copied, otherwise I would not had to search for it! However, I did not trust

I manually copied that file now to replace that other one, also removed the VCruntime140.DLL, which was required by the latest fashion of OpenSSL.EXE, compiled with no problem and re-fetched the certificates. They have the same validity period as the one I fetched yesterday, so I expect that all is working now as planned. Check!

Lets blame it on the IDE.

>> The most recent version, because the output of old versions of OpenSSL.EXE provided by SC and Capesoft are utilizing deprecated protocols, like SSL.

This is inaccurate.

As I said, based on my exprience with my previous efforts. And dates like 2015 did not raise my confidence, because of the returned errors. They told me that the used ciphers were not matching. "Oh no, not again..." Thats why I picked the newest OpenSSL.EXE I could find. And it worked out for, after some more choking.

But nonetheless I agree, if it would have worked out as it ought to do from the beginning, it would have been easier.

>> Based on my experience on making a self-signed web-certificate before with Nettalk 9,

Given the changes between NetTalk 9 and NetTalk 10, your experience with certificates in NetTalk 9 is likely not useful, and should be considered irrelevant.

You want to state that experience is irrelevant? I disagree and contradict.

When I issued my self-signed certificate with the OpenSSL.EXE I have had at my hands at that time, I had to learn that this one provided then was not only old, but also odd. It took me one day to find out, what was going wrong. The reason was apparently, that the OpenSSL.EXE I have had at that time was originally compiled with Cygwin, based on some Unix-Code. As I said before, it took my one day to learn, that I have to tinker with environment variables to let OpenSSL.EXE understand what to do where.

Being burnt once makes me act very cautiously, believe me. That was the reason why I laid out my experience with Let's Encrypt here in the forum. To discuss and learn.

[Bruce]

>> OpenSSL.EXE was not copied, otherwise I would not had to search for it!

That implies you have turned off file-copying for the project (or Clarion itself.) Or perhaps this is a DLL not an Exe?

>> As I said, based on my exprience with my previous efforts. And dates like 2015 did not raise my confidence, because of the
returned errors.

The files we ship are dated 2017, not 2015. Unfortunately your "experience" here is causing you more pain than help.

>> You want to state that experience is irrelevant? I disagree and contradict.

You are welcome to disagree. Unfortunately you went down completely the wrong road, causing lots more problems, based on your experience. Given the magnitude of the changes from NT9 to NT10, relying on NT9 experience will (and did) lead you astray.

>> It took me one day to find out, what was going wrong.

exactly. The approach you took was not helpful, and caused you a lot of wasted time.

<< Conclusion: We have to find a way to provide compatibility of the tools, so that not everyone has to repeat this frustrating process of try-and-error to find the correct tool du jour.

The most useful thing to take away from your efforts is that this was a good way of not to do things.
If you get stuck you should either ask for help, or read the documentation, that would be a better approach.

However, as an example of what not to do, your post is most valuable to other users.

cheers
Bruce

[bshields]