Using LetsEncrypt, I create, applied and verified an SSL certificate to the website and I can reach HTML or PHP files fine using https and see the Lock in the browser.
I followed these Xojo instructions to create a file MyApp.crt (certificate and private key data) in the folder holding the MyApp linux executable on a Centos 7 server. I use the command line shown below to launch MyApp and it gives no errors and runs fine.
I didn’t do anything else to the server other than adding that MyApp.crt file, kill the original executable and launch it again with the secureport parameter shown above.
Yes, the base name of my .crt file is the same as the app name. I tried to pose my question using generic names, but didn’t get it quite accurate.
The Xojo directions mention that if something goes wrong an error should be presented. I assume the error would be shown in the Terminal window and the process would abort. Instead there is no error, but only the non SSL URL on port 8080 works.
Yes, port 8081 is open for access. Here are other things I tried but can never reach the secure MyApp.
I used --port to run the non secure MyApp on a different port and the secure App on 8080.
I successfully ran the non secure MyApp on 8081.
I tried to run the secure MyApp on 443, but https://mydomain.com:443 still presents the index.html file not the secure MyApp
I tried using --certificate parameter to provide the absolute path to MyApp.crt
I checked the MyApp.crt file again, added an empty line between each section and made sure there were no permission issues with that file on the server or the folder in which it resides.
Is my understanding correct that I don’t need to make any other changes on the server or in the compiled MyApp itself? I’m also using a 64-bit Linux MyApp if that is significant.
I wish there was some way to stimulate an error message so I knew what to investigate.
#If Not DebugBuild Then // Do not try to daemonize a debug build
If (args(1) = "start" Or args(1) = "-d") Then // Check for command-line parameter to daemonize
If Not App.Daemonize Then
System.Log( System.LogLevelCritical, "Could not daemonize the app.")
else
System.DebugLog("app is daemonized (run as service)")
End If
End If
A letsencrypt certificate by itself isn’t always accepted by a lot of browsers.
Your .crt file needs to contain the full chain of authority for your certificate.
Did you create the .crt file with your certificate + private key or did you include the chain.pem file, too?
Your letsencrypt directory should have a fullchain.pem file.
Start with fullchain.pem and append the privkey.pem to create your .crt file for Xojo.
[quote=466916:@John A Knight, Jr]Your letsencrypt directory should have a fullchain.pem file.
Start with fullchain.pem and append the privkey.pem to create your .crt file for Xojo.[/quote]
Yes, this is exactly what I did, so the .crt file looks like this and is located in the folder holding the MyApp executable:
After my last post, I saw the odd format displayed in browser for the .crt file. I rebuilt and uploaded the .crt using a plain text editor, then restarted MyApp on the server. Unfortunately, I get the same results, where this URL cannot make a connection.
The only time I had problems was when I had the authority certificate first (wrong order) for the Xojo copy of the .crt file.
-----BEGIN CERTIFICATE-----
MIIGWTCCBUGgAwIBAgISBLHKyEFhMDiGLLhW5s3fb7gNMA0GCSqGSIb3DQEBCwUA
...... rest of certificate issued to you
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
...... rest of certificate authority chain
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQD0gdRC07OLooU/
..... rest of your private key
-----END PRIVATE KEY-----
Also remember that the items are base64 encoded.
Case is significant and ‘+’, ‘/’, and ‘=’ are part of the encoding.
If your editor is modifying any of those, it will damage the certificate.
Are you saying that the original fullchain.perm file created by LetsEncrypt already has the certificates in the correct order or they should be switched when creating the MyApp.crt file?
By viewing that file in an editor, I cannot tell which is which.
I have tried both the original order and the reversed order when building the MyApp.crt without success. I also tried used TextEdit and a plain ASCII editor on Mac and using NotePad and MS Word on Windows to build the MyApp.crt file.
I have also examined the fullchain.pem and created MyApp.crt files in a Hex editor and do not see any unusual characters that would explain the odd bullet character that appears after posting my previous comments.
I forgot to ask, when you had problems were you presented with an error when running the executable in Terminal or given any other type of error notification in a log file somewhere?
I never see any errors, but when I try to use the secure URL Safari says can’t establish a secure connection. Chrome and Firefox on Mac says Secure Connection Failed or This site can’t be reached with the additional message
ERR_CONNECTION_RESET or PR_CONNECT_RESET_ERROR, respectively.
The fullchain.pem is already the correct order.
Yes, it is hard to tell because they are encoded.
The Mac editors would be best. I think Notepad changes the end of line characters.
You want to end up with fullchain.pem + privkey.pem in your MyApp.crt.
If you have shell access to your server:
[quote=467155:@Harold Halbleib]
ERR_CONNECTION_RESET or PR_CONNECT_RESET_ERROR, respectively.[/quote]
I got this result when the certificates were in the wrong order.
Remember that Lets Encrypt certificates need to renew every 3 months. So you’ll need to do it again.
Look into the certbot docs. There is a way to have that command automatically run after renewal.