Could you please provide a detailed step-by-step guide on how to use my own SSL certificate?
I have deployed Open edX, but when I use the automatic SSL certificate generation via Caddy, I encounter problems accessing the platform from the external network.
However, when I don’t use an SSL certificate, everything works fine, but the platform is not secure.
I would like to try installing my own certificate, and I believe this might solve the issue.
P.S
It turns out that the platform does not work on the internet even without an SSL certificate. The platform only works inside the corporate network, and even then, it’s not secured. What could be the reason for this?
When I enable automatic certificate generation, the platform also doesn’t work over the external network, and within the corporate network only the main page (i.e., lms.example.com) works — the MFE apps (like apps.lms.example.com) do not work.
P.S(2)
I checked using a DNS checker, and it shows that everything is working fine.
Hi @abylaikhan.suev.02
For a while when I was originally setting up my Tutor on a limited network that couldn’t use the LetsEncrypt certs, I came up with the following solution that might help you.
in the folder ~/.local/share/tutor/data/caddy/ I created a folder certs in there to store my certificates (private and public keys)
Note that this folder is only mounted into the Caddy container if HTTPS/WEBPROXY is enabled, as you can see in this template:
Then to get the TLS certs loaded into Caddy’s config, i created the following patch at $(tutor plugins printroot)/caddyfile_tls_patch.py
enable it with: tutor plugins enable caddyfile_tls_patch
and restart caddy with: tutor local stop caddy && tutor local start caddy -d
To verify your changes applied you can inspect the contents of /home/tutor/.local/share/tutor/env/apps/caddy/Caddyfile and you should find tls /data/certs/fullchain.pem /data/certs/privkey.pem appears in both the LMS and CMS blocks of the Caddy config.
To update/replace expired certs in the future, simply overwrite the keys in ~/.local/share/tutor/data/caddy/ and restart the caddy container, new certs should take effect immediately upon restart.
Have you enabled your port forwarding (80/443) on your firewall/router/reverse-proxy to ensure the requests reach your internal server from the web? As well as DNS records for your external access (typically this would be an A/CNAME record pointing to your firewall/internet IP)
auto-certificate generation requires that the server is reachable externally as this is part of the validation procedure to confirm you actually own the domain name you’re trying to register a certificate for
Yes, the records are in place. I checked using a DNS checker, and it shows that everything is working.
open.kaznu.kz, studio.open.kaznu.kz, apps.open.kaznu.kz
It would at least be worth trying i think, at least then you’d be able to confirm your services are functional.
I noticed when opening https://apps.open.kaznu.kz that it shows your current certificate is a wildcard for *.kaznu.kz which may not be sufficient, as far as I’m aware wildcards at the root domain don’t typically work for sub-subdomains, so you may need a cert for open.kaznu.kz (as your primary domain for the LMS) AND *.open.kaznu.kz as a wildcard for any additional subdomains like apps,studio,etc
another plugin you might find useful to test connectivity:
create file at ~/.local/share/tutor-plugins/caddyfile_server_up_test.py with contents:
from tutor import hooks
hooks.Filters.ENV_PATCHES.add_item(
(
"caddyfile-lms",
"""
# Custom route for LMS
handle_path /status{
respond "Caddy is online!" 200
}
"""
)
)
tutor plugins enable caddyfile_server_up_test && tutor local restart caddy to enable it then go to https://open.kaznu.kz/status in your browser and if you see a message Caddy is online! that means you can reach your server remotely
I followed all the instructions, and it worked for me — my site open.kaznu.kz opens securely (for now, only within my corporate network). However, it didn’t work for apps.open.kaznu.kz.
How can I make apps.open.kaznu.kz open securely as well, so that everything works and I can easily make it accessible on the Internet in the future for external connections?
I manually added the entry for testing, without using the patch for now, and apps.open.kaznu.kz started to open — but the connection is still not secure.
it looks like there is no caddyfile-mfe patch, I’ve created a PR to get this added, provided my proposition is approved.
This should at least work for now as a “band-aid solution”
it may be worth inspecting your cert to make sure its valid for your domains, try this: openssl x509 -in ~/.local/share/tutor/data/caddy/certs/fullchain.pem -text -noout | grep DNS
you should see a response like this DNS:open.kaznu.kz, DNS:*.open.kaznu.kz
For what it’s worth, I’m not seeing the expected page(s) or a valid cert when connecting to your server:
In reality, it turned out that second-level subdomain certificates are not supported, as you previously mentioned. Now I have a question: is it possible to set a wildcard certificate for open.kaznu.kz, and a free Let’s Encrypt certificate for apps.open.kaznu.kz? That would definitely solve my problem.
Yes, LE does support wildcards but when you are using Certbot to get a LetsEncrypt cert you must specify all the domains you need, for example: certbot -d open.kaznu.kz -d "*.open.kaznu.kz" --preferred-challenges dns certonly
I suspect part of the major issues you are having is that your server is not reachable externally at all, if your server was correctly reachable via the internet through your corporate network/firewall then the whole certificate generation process should be automatic and you wouldn’t have to do anything fiddly like this.
If your corporate network has a firewall router (i should hope so ) then you may want to have your IT/network admin confirm they are correctly forwarding port 80/443 to your Tutor server’s internal network IP address. If you have multiple web servers/services running from your corporate network then 80/443 are probably already in use, so they might have a reverse proxy that handles the delivery/routing of multiple webservers that share a port, so that might be a good place to check if they’ve correctly configured the service routing for your Tutor server. Once that’s resolved you should have a much easier time enabling HTTPS without fiddling with patches, it should ‘just work’
Why is it that, at the very beginning, when I specified the domain open.kaznu.kz for LMS, and its subdomain becomes apps.open.kaznu.kz, and I choose automatic certificate generation, open.kaznu.kz works with a secure connection, but apps.open.kaznu.kz is accessed over an insecure connection? (That’s why I asked whether it’s possible to set a separate certificate for apps.open.kaznu.kz). The network administrator is asking that everything work securely inside the network, so that the platform can later be exposed to the external network. Honestly, I don’t fully grasp all the nuances here — is the problem only on my side, or is there a reason related to the network administrator as well?
p.s Maybe automatic certificate issuance doesn’t work for sub-subdomains (i.e., second-level subdomains like apps.open.kaznu.kz
Why is it that, at the very beginning, when I specified the domain open.kaznu.kz for LMS, and its subdomain becomes apps.open.kaznu.kz, and I choose automatic certificate generation, open.kaznu.kz works with a secure connection, but apps.open.kaznu.kz is accessed over an insecure connection? (That’s why I asked whether it’s possible to set a separate certificate for apps.open.kaznu.kz). The network administrator is asking that everything work securely inside the network, so that the platform can later be exposed to the external network. Honestly, I don’t fully grasp all the nuances here — is the problem only on my side, or is there a reason related to the network administrator as well?
p.s Maybe automatic certificate issuance doesn’t work for sub-subdomains (i.e., second-level subdomains like apps.open.kaznu.kz
p.s Sorry open.kaznu.kz also not working when i automate certificate generate
Your base URL is open.kaznu.kz and then the subdomains will be for any other additional services that form part of Tutor/OpenEdX, which is why the wildcard makes it more convenient so you don’t need to specify every domain that might be used
Then this definitely explains why the auto-generation of certs does not work and why you can’t access it externally, your admin is basically saying prove to me that it works internally before I’ll let you access over the internet. In this case, as I mentioned before: you want ONE certificate that’s valid for BOTH open.kaznu.kz AND *.open.kaznu.kz which you can get with certbot -d open.kaznu.kz -d "*.open.kaznu.kz" --preferred-challenges dns certonly
So you’ll get your certificate like that, patch it into your caddyfile so it uses your custom certificate, show your admin that it’s working so they can say they’re satisfied with the security and enable web access for your server. Once that’s all working and you can access it externally, then you can un-patch your caddyfile (remove the tls directives from all the server blocks) and now you should be able to auto-generate certificates when you run tutor local launch
Thank you very much for the help you provided. I hope everything goes well in your life, and I’m sure there is a special place in heaven for people like you .
Hi @abylaikhan.suev.02
In case you (or anyone else digging up this topic in future) needs to do this again, we now have an added patch for caddyfile-mfe-proxy
) then you may want to have your IT/network admin confirm they are correctly forwarding port 80/443 to your Tutor server’s internal network IP address. If you have multiple web servers/services running from your corporate network then 80/443 are probably already in use, so they might have a reverse proxy that handles the delivery/routing of multiple webservers that share a port, so that might be a good place to check if they’ve correctly configured the service routing for your Tutor server. Once that’s resolved you should have a much easier time enabling HTTPS without fiddling with patches, it should ‘just work’
.