Specify key_type for one domain

1. Caddy version (caddy version):

v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

2. How I run Caddy:

a. System environment:

Ubuntu 18.04

b. Command:

caddy reload

d. My complete Caddyfile or JSON config:

https://mail.domain.com {
    tls yourcurrentemail@gmail.com {
        key_type  rsa2048
    }
}

3. The problem I’m having:

I’m trying to change the key type for one domain in order to generate keys for GitHub - docker-mailserver/docker-mailserver: Production-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam, Antivirus, etc.) running inside a container.

4. Error messages and/or full log output:

reload: adapting config using caddyfile: parsing caddyfile tokens for 'tls': Caddyfile:68 - Error during parsing: unknown subdirective: key_type

5. What I already tried:

I tried adding the key_type to the tls directive of the domain.

6. Links to relevant resources:

The following forum post seems to indicate this should work:

Though key_type is not mentioned in the directive documentaton.

This issue on the docker mailserver github also suggests this solution, but may be for v1.

Currently key_type is only available as a global option in the Caddyfile:

If you need deeper customization, you’ll need to use JSON configuration instead. You can convert your current config to JSON with the caddy adapt command.

1 Like

Thanks for the reply. How difficult would it be to enable this in the Caddyfile? I’m willing to try to make a PR but have only got limited go experience.

In the mean time I have generated the json and modified the tls section like this:

		"tls": {
			"automation": {
				"policies": [
					{
						"issuer": {
							"email": "my@email.com",
							"module": "acme"
						}
					},
					{
						"subjects": [
							"mail.domain.com"
						],
						"key_type": "rsa2048",
						"issuer": {
							"email": "my@email.com",
							"module": "acme"
						}
					}
				]
			}
		}

Is that correct? It doesn’t seem to have modified the keys, do I need to delete the old ones?

I’m pretty sure that order matters for the policies, you’ll likely need to swap them so the most specific one is matched first.

I’m not sure whether you need to get rid of the old keys, you could try backing them up from your data directory to see if they generate differently for you.

It’s a tricky problem. The tls directive is per-site, but in JSON the tls app is “global”. We have some pretty complex logic that consolidates TLS settings when adapting to JSON. I think @matt will need to decide if this is something worth exploring.

Swapping the order of the policies and deleting the old keys worked. Thanks :slight_smile:

I don’t think it’s difficult. We already do similar logic for the ACME account email address and such. Just doesn’t seem very useful to have different key types. Why do you need this feature in the Caddyfile?

I wanted the rsa2048 keys to use with docker-mailserver (all in one self hosted mail server stack container) which currently doesn’t support the default keys (EC?). I don’t know if that issue is specific to the docker image, or some element of the tech within.

I’m managing my Caddy config manually as its just for my personal server with various apps running so it would be nicer to use the Caddyfile syntax as opposed to the full json structure.

Well, I think you’re the first to ask for that feature (in the Caddyfile, specifically – since it can already be done in the JSON).

It’s not a high priority for me to implement at this time but we could review a PR if you wanted to jump on it. Otherwise, just choose a maximally-compatible key type globally in the meantime, or tweak the JSON (it’s really not that bad, just explore the structural docs for a bit - I hand-craft or fine-tune JSON configs all the time).

Yeh you are right, the JSON is not nearly as daunting as it first looks and I’ve now got my config in YAML so its almost as concise as the Caddyfile format.

Thanks for all the help, very pleased with Caddy atm :slight_smile:

2 Likes

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