Managing certificates for Jellyfin server

When I configure caddy to manage a certificate for a domain it doesn’t serve, the console doesn’t mention it.

My config file:

{
	"apps": {
		"http": {
			"servers": {
				"srv0": {
					"listen": [
						":443"
					],
					"routes": [
						{
							"handle": [
								{
									"handler": "subroute",
									"routes": [
										{
											"handle": [
												{
													"handler": "reverse_proxy",
													"upstreams": [
														{
															"dial": "localhost:8096"
														}
													]
												}
											]
										}
									]
								}
							],
							"match": [
								{
									"host": [
										"jellyfin.mydns.duckdns.org"
									]
								}
							],
							"terminal": true
						}
					]
				}
			}
		},
		"tls": {
			"certificates": {
				"automate": [
					"mydns.duckdns.org"
				]
			}
		}
	}
}

Jellyfin enables automatic certificate management for the served sub-subdomain, but doesn’t say anything about managing certs for the subdomain appended to the tls / certificates section of the config file. Should I worry about it ?

Microsoft Windows [version 10.0.18363.815]
(c) 2019 Microsoft Corporation. Tous droits réservés.

C:\WINDOWS\system32>caddy run --resume
2020/04/25 14:07:20.464 e[34mINFOe[0m   resuming from last configuration
        {"autosave_file": "C:\\Users\\me\\AppData\\Roaming\\Caddy\\autosave.json"}
2020/04/25 14:07:20.471 e[34mINFOe[0m   admin   admin endpoint started  {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["localhost:2019", "[::1]:2019", "127.0.0.1:2019"]}
2020/04/25 14:07:20.473 e[34mINFOe[0m   http    server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv0", "https_port": 443}
2020/04/25 14:07:20.473 e[34mINFOe[0m   http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2020/04/25 16:07:20 [INFO][cache:0xc00068e460] Started certificate maintenance routine
2020/04/25 14:07:20.618 e[34mINFOe[0m   tls     cleaned up storage units
2020/04/25 14:07:20.619 e[34mINFOe[0m   http    enabling automatic TLS certificate management   {"domains": ["jellyfin.mydns.duckdns.org"]}
2020/04/25 14:07:20.633 e[34mINFOe[0m   autosaved config        {"file": "C:\\Users\\me\\AppData\\Roaming\\Caddy\\autosave.json"}
2020/04/25 14:07:20.633 e[34mINFOe[0m   serving initial configuration

I also split this reply out @CutterXYZ so that we can keep the wiki tidy and on-topic.

Does the certificate for mydns.duckdns.org appear in your data directory? If so, then it should be just fine. The particular log entry you’re referring to is emitted by the HTTP app, not the TLS app.

If it’s helpful we could add more debug logging to the TLS app.

It does, but it was created when caddy was configured to serve this domain.

It would be helpful to have more logging from the TLS app, yes, thanks. :slight_smile:

Is the certificate for jellyfin.mydns.duckdns.org not managed by the tls app ?

1 Like

Okay, that’s good then – assuming that nothing about the environment has changed (like $HOME) and that certificate isn’t close to expiring yet (probably not, if you only recently set it up), then there’s nothing for Caddy to do with it right now. Give it < 60 days and you should see something in the logs about it renewing.

Yeah I’ll work on that.

It is, but only implicitly in your case because it only appears in your config in the http app. Because it is implicit, I figured it was prudent to emit logs in that case. But I can add whatever other debug logs we need to.

1 Like

OK. Since tls manages that, wouldn’t it be better if tls reported it in the logs, instead of http ?

The TLS app doesn’t really know about it because it’s not part of its configuration.

But it’s the implicit behavior that gets logged, so you know it is happening. Contrast that with explicitly configuring the TLS app to manage your certificate. You never asked the HTTP app to manage your certificate, yet it is doing that for you anyway, so it is implicit, so we log it.

OK but if the tls app starts logging these events, the same event would be logged twice: once by http, a second time by tls ? Unless tls knows which events are implicit.

I was planning on making the TLS app’s logs for this stuff on the debug level, so they wouldn’t even appear in the logs unless you enable debug logging.

Logging something twice isn’t really bad – technically it’s not even logging twice – it gives you a causal relationship, which is valuable sometimes. :man_shrugging:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.