Allow Configuraiton of DNS Name of Cert Warden Client

[gregtwallace]

Cert Warden currently notifies clients using the Subject field DNS name. Allow a separate configuration option.

[peanutlasko]

Thanks for tracking this !

[gregtwallace]

I was thinking about this more and am not sure it would be useful.

The client currently runs on HTTPS and uses the certificate that it acquires from CW. Therefore, the dns name used for CW to connect to the client would have to be a dns name on the certificate. There could be some utility in allowing a choice of any one of the alt names, but I could just clarify the documentation that the subject is the domain name used for communication with the client.

Thoughts?

[peanutlasko]

Let me give you my use-case, and you punch any holes or things I might be overlooking.

• I have a domain cert with a wildcard. Example: peanut.com & *.peanut.com

• I have lots of apps in my homelab, some of them I want exposed to the internet, some I dont.

• Ideally, I'd like to use a sub-domain for my local-only apps (*.home.peanut.com), so that my wildcard cert will stlll be good.

I have 2 reverse proxies setup:

One is strictly for internet facing apps, these apps use the .peanut.com domain format
Second is for internal-apps only - .home.peanut.com

Reverse proxies are nice because they can translate an IP:PORT to a standard hostname AND they can do https, even on the local LAN.

I've also got a Unifi docker container which requires its own cert store. I've also got another app which requires me to keep my cert updated.

So, in this example I'd like to do the following:

Have Cert Warden run on my primary Docker host. It renews the cert from LetsEncrypt. Now I need Certwarden Client to also take that newly updated cert, and place the key and cert files into a specific place where my docker containers (~/,certs).

All of this works fine, EXCEPT the Certwarden Client. Since my cert is peanut.com, it tries to connect to https://peanut.com:5055/certwardenclient/api/v1/install, which I dont want since that points to my firewall on an un-opened port.

Ideally, I want to be able to configure this, and say connect to https://certwarden-client.home.peanut.com (which the reverse proxy will handle the ports).

Unless i've just overlooked something in my setup where I could make this also happen without a config option, then I'm 100% in agreement the documentation should at least inform the user.

[gregtwallace]

I knew I was forgetting something from the first time I thought this thorugh when I opened the issue: wildcard certificates. Thanks for the reminder :)

[joelgriffiths]

I inherited a certwarden installation on Docker Swarm (the original maintainer left last week). We're using a wildcard cert with many subdomains, and v0.22.2. Post process just throws this same error:

2024-12-18T16:18:07.216Z error orders/post_process_do_client.go:104 orders: post processing worker 2: order 35: notify client failed: failed to post to client (Post "https://bigdomain.com:5055/certwardenclient/api/v1/install": dial tcp: lookup bigdomain.com on 127.0.0.11:53: no such host) (cert: 2, cn: bigdomain.com)

I'm not sure where to go from here. Our certs expire next week and I'm supposed to be on vacation that week. :(

It doesn't look like this has been updated since this issue was filed. Do I have any options?

Sorry, I'm coming into this with very little knowledge, and I'm trying to reverse engineer it before I leave for vacation after tomorrow. :(

[gregtwallace]

I inherited a certwarden installation on Docker Swarm (the original maintainer left last week). We're using a wildcard cert with many subdomains, and v0.22.2. Post process just throws this same error:

2024-12-18T16:18:07.216Z error orders/post_process_do_client.go:104 orders: post processing worker 2: order 35: notify client failed: failed to post to client (Post "https://bigdomain.com:5055/certwardenclient/api/v1/install": dial tcp: lookup bigdomain.com on 127.0.0.11:53: no such host) (cert: 2, cn: bigdomain.com)

This is probably not related to this issue. I'm guessing your error is a red herring for however the certificates are supposed to be installed, but that's a guess.

Given your timeline, I'd manually install the new certificates into your environment which will extend your deadline and allow you to troubleshoot after you return from vacation.