logo
Apache Lounge
Webmasters

 


About

Forum Index Downloads Search Register Log in  RSS Apache Lounge
 


Keep Server Online

If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.

or

Bitcoin

A donation makes a contribution towards the costs, the time and effort that's going in this site and building.

Thank You! Steffen

Apache Lounge is not sponsored.

Your donations will help to keep this site alive and well, and continuing building binaries.



Trying to run Let's ecnrypt SSL on Apache 2.4 Windows

 
Post new topic   Reply to topic    Apache Forum Index -> Apache



View previous topic :: View next topic  
Author Message
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Tue 22 Jan '19 15:28    Post subject: Trying to run Let's ecnrypt SSL on Apache 2.4 Windows Reply with quote

Hi!

Steffen, thanks for that's mini how-to ( https://www.apachelounge.com/viewtopic.php?p=35959 ), but I was unable to run Let's Encrypt SSL on my Apache 2.4.34 VC15 x64. I modified my configs accordingly to the manual, ensured that md_mod is part of my current Apache installation, all module files are in place, fixed all httpd.exe run fails reasons, fixed all config syntax errors, and... it doesn't work, LOL! I can connect to my domain.dom:443 by telnet client and server listening the port and responding as should. But browsers don't like the answers: Chrome says ERR_SSL_PROTOCOL_ERROR, but Mozilla says The certificate is not trusted because it is self-signed. The certificate is only valid for . Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT.

SSL error log with proper config setting shows this:

Code:
[Tue Jan 22 15:51:34.841123 2019] [ssl:warn] [pid 176:tid 340] AH10085: Init: domain.dom:443 will respond with '503 Service Unavailable' for now. This host is part of a Managed Domain, but no SSL certificate is available (yet).
[Tue Jan 22 15:51:35.203143 2019] [md:debug] [pid 4236:tid 236] mod_md.c(1109): AH10076: domain.dom: manages server domain.dom
[Tue Jan 22 15:51:35.204143 2019] [md:debug] [pid 4236:tid 236] mod_md.c(1161): AH10113: md_get_certificate called for vhost domain.dom.
[Tue Jan 22 15:51:35.204143 2019] [md:debug] [pid 4236:tid 236] mod_md.c(1222): AH10116: domain.dom: providing fallback certificate for server domain.dom

Looks like missed certificates. It might be. Because I did not downloaded anything personally, like additinal binaries, ACME, any kind of exe or scripts or LE clients, any .crt/.key files, etc. I didn't run any commands from CMD, like certificate generation, domain validation, etc. Maybe problem is here, but I don't have proper expertise and definitely not Apache/SSL guru.

But, my 'md' directory contains these files:

Code:
C:\Apache2\md\staging\domain.dom\account.json
C:\Apache2\md\staging\domain.dom\authz.json
C:\Apache2\md\httpd.json
C:\Apache2\md\staging\domain.dom\job.json
C:\Apache2\md\staging\domain.dom\md.json
C:\Apache2\md\domains\domain.dom\md.json
C:\Apache2\md\md_store.json
C:\Apache2\md\staging\domain.dom\account.pem
C:\Apache2\md\domains\domain.dom\fallback-cert.pem
C:\Apache2\md\domains\domain.dom\fallback-privkey.pem
C:\Apache2\md\challenges\www.domain.dom\acme-http-01.txt
C:\Apache2\md\challenges\domain.dom\acme-http-01.txt

Please advise!


Last edited by EIKA on Tue 22 Jan '19 21:42; edited 1 time in total
Back to top
Steffen
Moderator


Joined: 15 Oct 2005
Posts: 2736
Location: Hilversum, NL, EU

PostPosted: Tue 22 Jan '19 16:23    Post subject: Reply with quote

I do not use mod_md, maybe users mono302 or DnvrSysEngr can help.

It looks good for me mod_md adds a temp certificate (selfsigned) in the md/staging.

When I recall the real certificate is there after a restart of Apache.

The certificate are stored in the folder /mb/domains/

Is this the complete ssl log ? When there is more then please use http://apaste.info/

To see maybe more add:

LogLevel info ssl:notice


Last edited by Steffen on Tue 22 Jan '19 16:32; edited 1 time in total
Back to top
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Tue 22 Jan '19 16:32    Post subject: Reply with quote

Current logging level is:
Code:
LogLevel info md:trace2 ssl:notice

Log repeats the same 4 lines with every server call. No more info.
Back to top
Steffen
Moderator


Joined: 15 Oct 2005
Posts: 2736
Location: Hilversum, NL, EU

PostPosted: Tue 22 Jan '19 16:32    Post subject: Reply with quote

Like to see all the log after you restart Apache.

Did you restart ?


Last edited by Steffen on Tue 22 Jan '19 16:40; edited 1 time in total
Back to top
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Tue 22 Jan '19 16:39    Post subject: Reply with quote

Steffen wrote:
Did you restart ?

Many times. And just repeated 2 times right now.

Before restart, 'md' subfolders were empty. But now they have something.
Back to top
Steffen
Moderator


Joined: 15 Oct 2005
Posts: 2736
Location: Hilversum, NL, EU

PostPosted: Tue 22 Jan '19 16:42    Post subject: Reply with quote

Like to see all the log after you restart Apache.

You can post the log at http://apaste.info/


For help you can also post at https://httpd.apache.org/lists.html#http-users and refer to this post.
Back to top
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Tue 22 Jan '19 16:55    Post subject: Reply with quote

I think that problem is related with no auth for domain.dom (DNS validation absence for LE). I did nothing to validate it, but I think that I must do something, like TXT records.

Because I see these lines in error.log, regular one:
Code:
[Tue Jan 22 17:45:17.556730 2019] [md:error] [pid 1972:tid 300] ACME server authz: challenge 'invalid' for domain.dom at https://acme-v01.api.letsencrypt.org/acme/authz/*.
[Tue Jan 22 17:45:17.958753 2019] [md:error] [pid 1972:tid 300] ACME server authz: challenge 'invalid' for www.domain.dom at https://acme-v01.api.letsencrypt.org/acme/authz/*.
[Tue Jan 22 17:45:18.352776 2019] [md:error] [pid 1972:tid 300] ACME server authz: challenge 'invalid' for domain.dom at https://acme-v01.api.letsencrypt.org/acme/authz/*.
[Tue Jan 22 17:45:18.352776 2019] [md:error] [pid 1972:tid 300] (22)Invalid argument: domain.dom: unexpected AUTHZ state 3 at https://acme-v01.api.letsencrypt.org/acme/authz/*
[Tue Jan 22 17:45:18.352776 2019] [md:error] [pid 1972:tid 300] (22)Invalid argument: AH10056: processing domain.dom
Back to top
admin
Site Admin


Joined: 15 Oct 2005
Posts: 596

PostPosted: Tue 22 Jan '19 17:22    Post subject: Reply with quote

No, it is not related to DNS validation and TXT records.

Try to add a vhost with port 80 and same domain names, when recall it is necessary sometimes.

<VirtualHost *:80>
ServerAdmin all@domain.dom
ServerName domain.dom
ServerAlias www.domain.dom
..
..
..
</VirtualHost>
Back to top
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Tue 22 Jan '19 17:27    Post subject: Reply with quote

admin wrote:
<VirtualHost *:80>
ServerAdmin all@domain.dom
ServerName domain.dom
ServerAlias www.domain.dom
..
..
..
</VirtualHost>

It does exist and serving clients all the time. SSL vhost section is copied off regular (port 80) site.


Last edited by EIKA on Tue 22 Jan '19 17:43; edited 1 time in total
Back to top
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Tue 22 Jan '19 17:32    Post subject: Reply with quote

This problem is definetly related with domain auth, because from error.log I clearly see that both kind of auth (dns-01 and http-01) has failed.
Code:
Exact repsonse was: {"identifier":{"type":"dns","value":"domain.dom"},"status":"invalid","expires":"2019-01-29T14:35:16Z","challenges":[{"type":"dns-01","status":"invalid","uri":"https://acme-v01.api.letsencrypt.org/acme/challenge/*","token":"hidden"},{"type":"http-01","status":"invalid","error":{"type":"urn:acme:error:unauthorized","detail":"Invalid response from http://domain.dom/.well-known/acme-challenge/ \\"


Exact repsonse was: {"identifier":{"type":"dns","value":"www.domain.dom"},"status":"invalid","expires":"2019-01-29T14:35:17Z","challenges":[{"type":"http-01","status":"invalid","error":{"type":"urn:acme:error:unauthorized","detail":"Invalid response from http://www.domain.dom/.well-known/acme-challenge/ \\"
Back to top
admin
Site Admin


Joined: 15 Oct 2005
Posts: 596

PostPosted: Tue 22 Jan '19 17:47    Post subject: Reply with quote

Still nothing to do with DNS TXT it.

Why you not post the complete log.
Back to top
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Tue 22 Jan '19 18:02    Post subject: Reply with quote

Full log (from Apache restart to a few calls)
Back to top
pbhq



Joined: 17 Mar 2013
Posts: 37
Location: Germany

PostPosted: Tue 22 Jan '19 18:06    Post subject: Reply with quote

EIKA wrote:
Full log (from Apache restart to a few calls)


What's that in your logfile: Question Question


http://angela.timeweb.ru/parking/?ref=domain.dom","hostname":"angela.timeweb.ru
Back to top
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Tue 22 Jan '19 18:12    Post subject: Reply with quote

pbhq wrote:
What's that in your logfile: Question Question

This is how md_mos's domain auth works. It queries DNS records for domain.dom, checks TXT recodrs and follows IP any addresses from there. Even when this record doesn't contain _acme-challenge. host. In my case, ACME followed SPF TXT record and resolved host, IPv6, etc. I don't know why it does it, it's a question to the author(s) of client or/and mod.


Last edited by EIKA on Tue 22 Jan '19 18:41; edited 1 time in total
Back to top
admin
Site Admin


Joined: 15 Oct 2005
Posts: 596

PostPosted: Tue 22 Jan '19 18:20    Post subject: Reply with quote

You can remove the link to the file in above post (privacy reason)

mod_md uses http-01 fot validation/auth,

I see

Code:
{"type":"http-01","status":"invalid","error":{"type":"urn:acme:error:unauthorized","detail":"Invalid response from http://domain.dom/.well-known/acme-challenge/pUW42UrW2utYSQ0zniMCXbvw2VN_T9lQXiMGvyxQU-s: \\"<!doctype html>\\\\n<html class=\\\\\\"no-js\\\\\\" xmlns=\\\\\\"http://www.w3.org/1999/html\\\\\\">\\\\n<head>\\\\n    <script src=\\\\\\"https://cdn.optimizely.com/js/4\\"","status":403},"uri":"https://acme-


"status":403

Maybe yoy block some, mod_security ?

Look in your log for: http://domain.dom/.well-known/acme-challenge/pUW42UrW2utYSQ0zniMCXbvw2VN_T9lQXiMGvyxQU-s
Back to top
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Tue 22 Jan '19 18:36    Post subject: Reply with quote

This link
Code:
http://domain.dom/.well-known/acme-challenge/pUW42UrW2utYSQ0zniMCXbvw2VN_T9lQXiMGvyxQU-s

is freely available from Internet and provides some text string containing 88 characters.

mod_security was temporary disabled.

No changes.
Back to top
admin
Site Admin


Joined: 15 Oct 2005
Posts: 596

PostPosted: Tue 22 Jan '19 20:57    Post subject: Reply with quote

Saw you posted this issue also at mod_md git, lets wait what the author has to say.
Back to top
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Tue 22 Jan '19 21:42    Post subject: Reply with quote

Hold on, guys. I see some progress. Will update the thread soon.
Back to top
EIKA



Joined: 22 Jan 2019
Posts: 11
Location: Russia

PostPosted: Wed 23 Jan '19 15:13    Post subject: Reply with quote

Hi all!

Looks like problem has gone, but I have no exact explanation why.

1. I added appropriate DNS TXT records manually (see for e.g. this https://community.letsencrypt.org/t/how-to-add-dns-txt-record-for-domain-verification/31555 ). I removed them after some period of time for testing purposes (to exclude their influence). Because this step is not part of mod_md how-to manual, and looks like, isn't required at all.

2. I asked my hoster to remove AAAA record from my domain. It can't be deleted by the user, because if there is no user-defined AAAA record, hosting panel adds default AAAA record that points to the IP of the whole hosting server.

3. I re-worked a bit my configs.

4. I found serious and funny problem at the same time. TCP:443 port was actually listened by another application, but not Apache (it's due to NAT rule that forwarded TCP:443 packets to another TCP port). That's server (even non-HTTP) responded to telnet enquiries just fine and it's misled me.

Anyway, thanks for your participation. I will keep you informed in case of certificate renewal problems or other issues.
Back to top


Post new topic   Reply to topic    Apache Forum Index -> Apache
Page 1 of 1