Sure, you can post the certificate and the chain (just don't post the private key).
It would also be interesting to know more about how the web server is configured (for example, how and where did you tell it to use /WebserverPath/cert.pem?
1 Like
4D Web Server looks for cert.pem and key.pem in the application folder. This is no configuration for it and it just finds and loads it.
Then you may need to replace cert.pem with the contents of fullchain.pem
[that is the file you need]
Are you sure there is no way to change the configuration?
1 Like
Could you show us what is in cert.pem? Does it change from two certs to one cert when the problem occurs?
1 Like
Here's the cert.pem. It is identical to the file that worked on November 12th or so after the last time I forced renewal. It has not changed.
-----BEGIN CERTIFICATE-----
MIIFVDCCBDygAwIBAgISAwOpi/+e266iTJ3mkoCZwukRMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDExMTIxMTU3MzVaFw0y
MTAyMTAxMTU3MzVaMBoxGDAWBgNVBAMTD3NpbW9uNGQuYmVsLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKRewU+rYmYMMhtZeXcIYMRl1f5df3HU
vXnuP0pzRph0nuAJe8b6VqZiiSg+zBOp0xFfn4SsktFssVQF9XGtIDHXgqkmUpqU
7kEhn9eDkLn0mxWpkJProBhfJbXkb7+Hdz7n8SD/ecGt/hDOwTfei1pQjS07f5g2
7FUW+yYLLqafcNhFadn19fDCwD66JS9wpgCnYu3kDLQYlJC4ianpyyuMkTNogmGR
whKzJBGtv4Gz+ZRxVkxj6nYVFGq3da9hidVHH/MRyeAi+GZFc9a/1OEta++hcyxE
dluGLGUTOfMFsx0FtCBXsaBHYEcsoYa/pXNkciNJaiVNsjufvlMt4cECAwEAAaOC
AmIwggJeMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYB
BQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUYaaML6hxB/1F6sjQ6kfE/WoQ
dKUwHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl7/Oo7KEwbwYIKwYBBQUHAQEE
YzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5pbnQteDMubGV0c2VuY3J5cHQu
b3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5pbnQteDMubGV0c2VuY3J5cHQu
b3JnLzAaBgNVHREEEzARgg9zaW1vbjRkLmJlbC5jb20wTAYDVR0gBEUwQzAIBgZn
gQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5s
ZXRzZW5jcnlwdC5vcmcwggECBgorBgEEAdZ5AgQCBIHzBIHwAO4AdQCUILwejtWN
bIhzH4KLIiwN0dpNXmxPlD1h204vWE2iwgAAAXW8iGIGAAAEAwBGMEQCID5Da59W
gtRX5HmouMwxuPLM7XB178Fd0THxUpcYbDNPAiAIEfKvXLeMmh5unCXK1kP4x2fK
DmgGAWEzxXwNGXZIxQB1AH0+8viP/4hVaCTCwMqeUol5K8UOeAl/LmqXaJl+IvDX
AAABdbyIYkYAAAQDAEYwRAIgOCbOSALtSiQnd81SQA63eZR6hnhDsRGvxFUZtD7Q
C+kCIBGGo2LA2vkqFaY2hQO+iXZPLEBxtR7OL8scN8AE4MjTMA0GCSqGSIb3DQEB
CwUAA4IBAQAhT1xerBOjpqFWJ3jxctDF8R47XCoESW7z6P+WJWvy5rPua1JPZdcV
Xm89DWlzQx4j5duJ2qa0l5KXozzjf6v923MU/+Xy8lVzGjaKK3RXUO6raztgr0El
ecEGpHBDGtsRuBSTPpVUa1YeD0u5rDwb/rI96WWLcCcJWGI4nE1rYkxl7R5o3nF0
NLZrgZOt3J7gYfPtir+xiWELV0GS5VjLijKKUoH1e1vh3l69VKN10sdTqiLlA50m
CTzaC29sbZ/XCYUlN9HJlIDwRYNcLvIDq0zPiNKt31omJr/m/0OLLVK69uUyDPaN
i2StRTJALHRfQAinu0HuvhkuWIgw4xxB
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----The second one shows is X3.
So that is the correct cert to be using.
Can you show that URL and output?
I also saw the intermediate not showing up when I tried to connect directly before @muzicman82 fixed the problem.
@muzicman82 are you sure that 4D Web Server is directly answering all incoming requests, including during the times when the configuration gets messed up? There isn't some other web server or reverse proxy active at that time?
I feel like this is likely to be a bug in 4D Web Server, although, if so, it's a very unusual kind of bug.
Which URL are you talking about?
URL
Yes, there is no other Web Server or anything else running on this system. Also, it is running on port 440 and not port 443 because something in macOS X is blocking or high jacking 443 and I cannot get 4D Web Server to start on 443 no matter what I do. But, there's no reason 440 shouldn't work.
As far as TLS/SSL on 4D, there is no configuration or anything, which is why the certificate needs to be specific files and location on the drive.
Still doesn't explain why full chain breaks after time with no changes to the files. Is it possible for the certificate to be revoke or something?
I agree, this is super-weird.
It is logically possible for the certificate to be revoked, but certificate revocations are public and are unlikely to occur unless you request them. And there's no part of TLS specifications that says "a web server should respond to a revocation by continuing to use the revoked certificate except no longer including the certificate chain"!
Do you have a way to ask the 4D developers about what might be causing this?
1 Like
Don't really have a support chain. We're running v16 so we're a few versions behind without support. I've looked and asked around 4D Forums but it seems to me that people just drop the PEM files and move on.
I'm curious why SSL checkers are saying the full chain is broken when the files are clearly identical. Are there any SSL checkers that offer some sort of debug to the results?
Actually, I think by issuing --fullchain-file "/WebServerPath/cert.pem" I am telling the script to make the fullchain file with filename cert.pem in that path. It is working until it doesn't.
One SSL checker I've been using is this one: https://www.geocerts.com/ssl-checker
A test URL on the web server is this: https://simon4d.bel.com:440/fetch.html. Note that this was a test page for fetch XHR development. The webserver doesn't actually host any browser-facing pages.
You can test it yourself using openssl command:
echo | openssl s_client -connect simon4d.bel.com:440 -servername simon4d.bel.com -showcerts 2>/dev/null | grep '^ [0-1]'
Or if you are having issues to connect to your public ip from the internal network you can test it from the own machine using localhost (-servername parameter must remain with your actual domain):
echo | openssl s_client -connect localhost:440 -servername simon4d.bel.com -showcerts 2>/dev/null | grep '^ [0-1]'
And you should receive this output:
0 s:CN = simon4d.bel.com
1 s:C = US, O = Let's Encrypt, CN = R3
If you can't see the Let's Encrypt part then your web server is not serving the intermediate certificate.
Cheers,
sahsanu
2 Likes
I think you should get a screenshot of when it fails (it seems OK now).
1 Like
It's worth noting that if you need to work with a weird web server and it's just not behaving (or no longer supported) it's probably best not to expose that server directly to the internet and instead put a proxy web server such as caddy, nginx or Cloudflare (free, hosted) in front of it, that way the modern/supported web server is handling the communication with the client and your webserver is the only thing that needs to be able to talk to your backend server.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Hi all, this is a follow up to this thread since it is closed after 30 days.
The certificate broke again, and I don't see ANY difference in the PEM files since I made a copy of them the last time they were generated. I also checked the acme.sh logs and there was no renewal activity (which would happen in March).
What's next? I posted on a 4D group to see if those folks have any ideas. I'm wondering if the web server is caching the certificate and then breaking itself somehow.... and then when I force renewal the files are different, so it loads the new files. This is just speculation.
1 Like
Welcome back! 
Currently, both ports 80 (http) and 443 (https) are closed for simon4d.bel.com, so I'm unable to run any tests.
1 Like