Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No certificate available #2895

Closed
focux opened this issue Nov 22, 2019 · 13 comments

Comments

@focux
Copy link

@focux focux commented Nov 22, 2019

1. Which version of Caddy are you using (caddy -version)?

Caddy v1.0.4

2. What are you trying to do?

I've been trying for two days to make the TLS on-demand to work and I haven't had any luck.

3. What is your Caddyfile?

* {
    log stdout
    root ./www
    browse
    gzip
    tls {
     ask https://www.google.com
    }
}

*.thridea.com:443 {
    root ./www
    browse
    gzip
    log stderr
    errors stderr
    tls /etc/letsencrypt/live/thridea.com/fullchain.pem /etc/letsencrypt/live/thridea.com/privkey.pem
}

4. How did you run Caddy (give the full command and describe the execution environment)?

It's a new DigitalOcean VPS that I bought to test and play with Caddy, I don't have anything else in front of it. Also, It's a fresh Caddy installation built from the source.

To run caddy, I use the following command:
caddy -log stdout

5. Please paste any relevant HTTP request(s) here.

root@production-app:~/caddy# curl http://bookme.rocks
<a href="https://bookme.rocks/">Moved Permanently</a>.
root@production-app:~/caddy# curl https://bookme.rocks
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

6. What did you expect to see?

I expect first, to be asked what's my email, then to agree to the LE TOS and then to see the TLS succeed.

7. What did you see instead (give full error messages and/or log)?

Nov 22 19:47:16 production-app caddy[13291]: [INFO] Serving https://*
Nov 22 19:47:16 production-app caddy[13291]: Serving HTTP on port 80
Nov 22 19:47:16 production-app caddy[13291]: http://*
Nov 22 19:47:16 production-app caddy[13291]: [INFO] Serving http://*
Nov 22 19:47:16 production-app caddy[13291]: [INFO][cache:0xc0000a07d0] Started certificate maintenance routine
Nov 22 19:47:17 production-app caddy[13291]: [INFO] Sending telemetry: success
Nov 22 19:47:22 production-app caddy[13291]: http: TLS handshake error from 179.53.91.106:49397: no certificate available for 'www.bookme.rocks'
Nov 22 19:47:22 production-app caddy[13291]: http: TLS handshake error from 179.53.91.106:49398: no certificate available for 'www.bookme.rocks'
Nov 22 19:47:23 production-app caddy[13291]: http: TLS handshake error from 179.53.91.106:46429: no certificate available for 'www.bookme.rocks'
Nov 22 19:47:34 production-app caddy[13291]: http: TLS handshake error from 179.53.91.106:49428: no certificate available for 'www.bookme.rocks'

8. Why is this a bug, and how do you think this should be fixed?

So, basically this block works perfect, if I go to something.thridea.com or www.thridea.com it works.

*.thridea.com:443 {
    root ./www
    browse
    gzip
    log stderr
    errors stderr
    tls /etc/letsencrypt/live/thridea.com/fullchain.pem /etc/letsencrypt/live/thridea.com/privkey.pem
}

What doesn't work is this block, that's why I think it's related to TLS on-demand:

* {
    log stdout
    root ./www
    browse
    gzip
    tls {
     ask https://www.google.com
    }
}

When I try to use e.g. bookme.rocks, is when I get the error I showed above.

9. What are you doing to work around the problem in the meantime?

I don't really know what I can do as a workaround.

10. Please link to any related issues, pull requests, and/or discussion.

Related to #2773

@mholt

This comment has been minimized.

Copy link
Member

@mholt mholt commented Nov 22, 2019

tls /etc/letsencrypt/live/thridea.com/fullchain.pem /etc/letsencrypt/live/thridea.com/privkey.pem

I believe thridea.com is not a valid certificate for www.domain.com. The solution is simple: you have to provide a certificate that is valid for www.domain.com.

@mholt mholt closed this Nov 22, 2019
@focux

This comment has been minimized.

Copy link
Author

@focux focux commented Nov 22, 2019

Actually thridea.com is a valid certificate, and it works perfectly. What doesn't work is the first block:

* {
    log stdout
    root ./www
    browse
    gzip
    tls {
     ask https://www.google.com
    }
}
@mholt

This comment has been minimized.

Copy link
Member

@mholt mholt commented Nov 22, 2019

@focux

Actually thridea.com is a valid certificate, and it works perfectly.

What do you mean "it works perfectly"? I thought you were getting no certificate available for 'www.domain.com'. How is that working perfectly?

@focux

This comment has been minimized.

Copy link
Author

@focux focux commented Nov 22, 2019

@focux I think I made a dumb mistake when trying to censor my domain name, sorry. The error is complaining about another domain that is not *.domain.com:443 . Sorry for bringing confusion.

@mholt

This comment has been minimized.

Copy link
Member

@mholt mholt commented Nov 22, 2019

Please update your issue with the complete and unredacted information then, please, as the issue template instructions state:

paste entire Caddyfile here - DO NOT REDACT ANYTHING (except credentials)

Similar for the logs:

DO NOT REDACT INFORMATION except for credentials. See https://caddy.community/t/how-to-get-help-with-caddy-more-effectively/5222

Also fill out question 5, that will help relieve the ambiguity in your report. Right now this is not actionable or reproducible.

@focux

This comment has been minimized.

Copy link
Author

@focux focux commented Nov 22, 2019

Alright, I added more context to the issue. Sorry for the inconvenient.

@mholt

This comment has been minimized.

Copy link
Member

@mholt mholt commented Nov 22, 2019

Can you please use real domain names? That is essential to solving the problem.

@focux

This comment has been minimized.

Copy link
Author

@focux focux commented Nov 22, 2019

Sure, just change back the names.

@mholt

This comment has been minimized.

Copy link
Member

@mholt mholt commented Nov 22, 2019

Okay, thanks. We're finally making some progress.

www.bookme.rocks does not match any site you have configured, and thus does not match any TLS certificate configuration you've given. You will need to change either * or *.thridea.com:443 (you can drop the :443 by the way) or add a new site to match www.bookme.rocks.

@focux

This comment has been minimized.

Copy link
Author

@focux focux commented Nov 22, 2019

What I want to do it's to generate SSL certificates on-demand for custom domains, without having to create a new site for each domain. I'm working on a multi-tenant product and I want to allow the customers to map his domain to his product URL.

@focux

This comment has been minimized.

Copy link
Author

@focux focux commented Nov 22, 2019

* {
    log stdout
    root ./www
    browse
    gzip
    tls {
     ask https://www.google.com
    }
}

I thought that this block was doing what I said above, generate TLS certificates on the flight, using LE.

@mholt

This comment has been minimized.

Copy link
Member

@mholt mholt commented Nov 22, 2019

According to the docs:

A site defined as * matches only one-label names like "localhost" but not "example.com". To match all hosts, leave the hostname empty.

This is because the relevant RFC (I forget its number right now, but it's mentioned several times on the issues here previously) restricts wildcards in this manner as they pertain to TLS certificates, and this same string value is what Caddy uses in its TLS certificate logic.

@focux

This comment has been minimized.

Copy link
Author

@focux focux commented Nov 22, 2019

Thank you so much, now it works perfectly. I had two days trying to find what I had wrong in my conf and it was as simple as that. Thank you again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.