Wildcard certs #18

New Issue

Ghost · 2019-11-16T02:15:40Z

Ghost commented

2019-11-16 02:15:40 +00:00

Hi,

First of all, thank you for your work on this project, it's really useful.

I am trying to get wildcard certs working, they seem to work by adding an altname of *.domain.com but that causes connection closed errors after a while.

What is the proper way of adding wildcard certs in version 3 and greater?

Thanks

Hi, First of all, thank you for your work on this project, it's really useful. I am trying to get wildcard certs working, they seem to work by adding an altname of *.domain.com but that causes connection closed errors after a while. What is the proper way of adding wildcard certs in version 3 and greater? Thanks

Ghost commented

2019-11-30 14:06:34 +00:00

I'm also having this same issue. My current workaround is to specify each individual altname like so:

npx greenlock add --subject example.com --altnames example.com, sub1.example.com,sub2.example.com

I hope this is correct, for now. But it would be nice to replace sub1 and sub2 and with *.

Thanks for the work you've done on this as well!

I'm also having this same issue. My current workaround is to specify each individual altname like so: `npx greenlock add --subject example.com --altnames example.com, sub1.example.com,sub2.example.com` I hope this is correct, for now. But it would be nice to replace sub1 and sub2 and with *. Thanks for the work you've done on this as well!

Ghost commented

2019-12-15 17:34:59 +00:00

You need to use dns-01 instead of http-01 validation to use wildcards.

I started looking into existing implementations, but I don't have domains with compatible providers (yet).

My question is, does this work with manually creating the TXT record once, or is it changed on renewal?
If it isn't, maybe we can have a useful example testadapter printing the TXT record to be set and just waiting five minutes, so we can set it manually?

You need to use `dns-01` instead of `http-01` validation to use wildcards. I started looking into existing implementations, but I don't have domains with compatible providers (yet). My question is, does this work with manually creating the TXT record once, or is it changed on renewal? If it isn't, maybe we can have a useful example testadapter printing the TXT record to be set and just waiting five minutes, so we can set it manually?

coolaj86 commented

2020-01-10 08:21:42 +00:00

does this work with manually creating the TXT record once, or is it changed on renewal

The records are new random tokens each time the certificate renews

maybe we can have a useful example testadapter printing the TXT record to be set and just waiting five minutes, so we can set it manually?

https://git.rootprojects.org/root/acme-dns-01-cli.js.git

> does this work with manually creating the TXT record once, or is it changed on renewal The records are new random tokens each time the certificate renews > maybe we can have a useful example testadapter printing the TXT record to be set and just waiting five minutes, so we can set it manually? https://git.rootprojects.org/root/acme-dns-01-cli.js.git

coolaj86 closed this issue

2020-01-10 08:21:42 +00:00

coolaj86 reopened this issue

2020-01-10 08:21:47 +00:00

Ghost commented

2020-04-04 12:23:02 +00:00

I'm also having this issue with wildcard certs.

The problem is not the issuance of wildcard certs, that works fine

The behaviour I am seeing is:

The first connection to any given subdomain connects succesfully, completing TLS negotiation and getting forwarded to (in my case) the express server.

The second connection to the same subdomain, is closed immediately (the client sends TLS Hello and the server just closes the connection)

Switching to a different subdomain, and the first connection will work, but subsequent connection will get closed immediately.

Restarting the server, will make the first request for any given subdomain work again.

Can reproduce this very reliably by using curl, which will always use a new connection.

I'm also having this issue with wildcard certs. The problem is not the issuance of wildcard certs, that works fine The behaviour I am seeing is: The first connection to any given subdomain connects succesfully, completing TLS negotiation and getting forwarded to (in my case) the express server. The second connection to the same subdomain, is closed immediately (the client sends TLS Hello and the server just closes the connection) Switching to a different subdomain, and the first connection will work, but subsequent connection will get closed immediately. Restarting the server, will make the first request for any given subdomain work again. Can reproduce this very reliably by using curl, which will always use a new connection.

Ghost commented

2020-04-30 07:06:22 +00:00

Hi

I'm also experiencing this issue with wildcard certs. I see the exact same behavior as aidanok. A request using a wildcard domain works for the first request, then following requests get a closed connection. You can send requests to a different subdomain of the wildcard cert and it works one time again.

I'm basically using the http-proxy example with added dns-01 challenge for the wildcard domain.

Hi I'm also experiencing this issue with wildcard certs. I see the exact same behavior as aidanok. A request using a wildcard domain works for the first request, then following requests get a closed connection. You can send requests to a different subdomain of the wildcard cert and it works one time again. I'm basically using the http-proxy example with added dns-01 challenge for the wildcard domain.

Ghost commented

2020-05-01 04:52:17 +00:00

Update on this. I fixed this in my fork here: cdeeff6a3f.

I can't see any option to raise a pull request. Is it because this is a mirrored reporitory?

Update on this. I fixed this in my fork here: https://git.rootprojects.org/warrickhunter/greenlock-express.js/commit/cdeeff6a3f8418d05835dae4b7586778fe85001c. I can't see any option to raise a pull request. Is it because this is a mirrored reporitory?

Ghost commented

2021-02-10 11:16:22 +00:00

I also have this problem. Thanks @warrickhunter for the fix!

Ghost commented

2021-02-16 22:19:57 +00:00

I experienced the same issue. I can confirm that @warrickhunter's patch resolvs the issue.

@coolaj86 Can we please get this(cdeeff6a3f) merged ASAP? Thanks!

PS: here also seems to be an issue with Gitea/NPM ineroperability that precludes use of packages (using HTTPS URLs) hosted on rootprojects.org from being referenced in package.json files (for insallation via NPM). They can be retrieved indicidually via git, but fail wen retrieval via NPM is atemped with a 100% repeatable error indicaing it can't find the package.json file related to the retrieved module.

I experienced the same issue. I can confirm that @warrickhunter's patch resolvs the issue. @coolaj86 Can we please get this(https://git.rootprojects.org/warrickhunter/greenlock-express.js/commit/cdeeff6a3f8418d05835dae4b7586778fe85001c) merged ASAP? Thanks! PS: here also seems to be an issue with Gitea/NPM ineroperability that precludes use of packages (using HTTPS URLs) hosted on rootprojects.org from being referenced in package.json files (for insallation via NPM). They can be retrieved indicidually via git, but fail wen retrieval via NPM is atemped with a 100% repeatable error indicaing it can't find the package.json file related to the retrieved module.

coolaj86 commented

2021-04-16 04:33:21 +00:00

Thanks for the update. I'll try to get this in on Saturday. If I don't, feel free to send me an email directly so that it doesn't get lost in my "forum updates" tab.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: root/greenlock-express.js#18