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?
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:
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’
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
I think it’ll be available in the next release of tutor-mfe, for now it is not added into the current v20.0.0 release, there are a few other updates sitting in release including this new patch
) 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’
.