Subdomain cert not recognized by SSL Labs


#21

Sorry, I don’t think those were the relevant lines of the file. I should have double-checked and scrolled up before posting. Try this:

Jan 14 16:56:35 enorugby.com sudo[23892]: pi : TTY=pts/0 ; PWD=/home/admin/conf/web ; USER=root ; COMMAND=/usr/sbin/service apache2 restart
Jan 14 16:56:35 enorugby.com sudo[23892]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
Jan 14 16:56:35 enorugby.com systemd[1]: Stopping The Apache HTTP Server…
– Subject: Unit apache2.service has begun shutting down
– Defined-By: systemd
– Support: http://www.ubuntu.com/support

– Unit apache2.service has begun shutting down.
Jan 14 16:56:35 enorugby.com apachectl[23898]: AH00526: Syntax error on line 44 of /home/admin/conf/web/drills.enorugby.com.apache2-le-ssl.conf:
Jan 14 16:56:35 enorugby.com apachectl[23898]: Name duplicates previous WSGI daemon definition.
Jan 14 16:56:35 enorugby.com apachectl[23898]: Action ‘stop’ failed.
Jan 14 16:56:35 enorugby.com apachectl[23898]: The Apache error log may have more information.
Jan 14 16:56:35 enorugby.com systemd[1]: apache2.service: Control process exited, code=exited status=1
Jan 14 16:56:36 enorugby.com systemd[1]: apache2.service: Failed with result ‘exit-code’.
Jan 14 16:56:36 enorugby.com systemd[1]: Stopped The Apache HTTP Server.
– Subject: Unit apache2.service has finished shutting down
– Defined-By: systemd
– Support: http://www.ubuntu.com/support

– Unit apache2.service has finished shutting down.
Jan 14 16:56:36 enorugby.com systemd[1]: Starting The Apache HTTP Server…
– Subject: Unit apache2.service has begun start-up
– Defined-By: systemd
– Support: http://www.ubuntu.com/support

– Unit apache2.service has begun starting up.
Jan 14 16:56:36 enorugby.com apachectl[23904]: AH00526: Syntax error on line 44 of /home/admin/conf/web/drills.enorugby.com.apache2-le-ssl.conf:
Jan 14 16:56:36 enorugby.com apachectl[23904]: Name duplicates previous WSGI daemon definition.
Jan 14 16:56:36 enorugby.com apachectl[23904]: Action ‘start’ failed.
Jan 14 16:56:36 enorugby.com apachectl[23904]: The Apache error log may have more information.
Jan 14 16:56:36 enorugby.com systemd[1]: apache2.service: Control process exited, code=exited status=1
Jan 14 16:56:36 enorugby.com sudo[23892]: pam_unix(sudo:session): session closed for user root
Jan 14 16:56:36 enorugby.com systemd[1]: apache2.service: Failed with result ‘exit-code’.
Jan 14 16:56:36 enorugby.com systemd[1]: Failed to start The Apache HTTP Server.
– Subject: Unit apache2.service has failed
– Defined-By: systemd
– Support: http://www.ubuntu.com/support

– Unit apache2.service has failed.


#22

not much help there…
I don’t see why it fails.
But you might be able to redo that part.
Try:

  1. remove that file form include (as if it never existed)
  2. delete the matching “TEST_CERT”
  3. reissue a new drills cert.
    [which should recreate a new drills SSL conf]

#23

STOP THE PRESSES:


#24

Those should probably be “drillssite” ?
Or removed altogether?


#25

I think it’s unhappy because those lines exist in both conf files for drills.enorugby, so it’s defining that process twice with the same name. I commented them out of the SSL file, and now I can restart apache. SSL Labs is happy too - no more name mistmatch!
Unfortunately, I still get the following error when trying to enable SSL support in VestaCP:
Error: Invalid response from http://drills.enorugby.com/.well-known/acme-challenge/7enk49tUNiyPXcLyQ7NZ-MqvPbdTqs71od9ed9RjtMU: \


#26

Ok, I’m wondering how you got the other one to work…
Please show:
grep -Eri 'virtual|known|acme|rewrite|root|servername|serveralias|sslcert' /home/admin/conf/web

[upload result as a text file]
image


#27

Last time I did this, I ran certbot --staging for enorugby.com, and I think the only real issue I had was that my SSL tests were failing because I was redirecting HTTP traffic to HTTPS. Once I commented out those lines, it worked in Vesta. I then uncommented them and never had a problem since.
As such, you may note that the conf file for enorugby.com has rewrite rules in it. I am not including those for drills.enorugby.com until after I get this working in Vesta. grep.txt (2.2 KB)


#28

hmm…
That’s not the rewrite I was hoping to find [unrelated to auth challenge requrests].

Ok we can still try:

Or just reissue a cert from prod [not staging].

then VestaCP


#29

Do you mean delete the drills.enorugby.com folder in the /etc/letsencrypt/live folder, or is there a better way to remove it?


#30

No.
certbot delete
To delete the cert only.


#31

No luck. I deleted the old cert and created a new one. I manually added the Include to the vesta.conf file. (Not sure why that’s not being added automatically - maybe that’s part of the problem.) I tested at both Lets Debug and SSL Labs, no issue. Same error when I try to enable SSL Suppport-Lets Encrypt Support in Vesta CP.
Error: Invalid response from http://drills.enorugby.com/.well-known/acme-challenge/pK1DYiV5EODCWGWRsV3A2yF67mRaVj0cFG_Dp6Lt4Ng: \

I did find the issue though! This folder/file .well-known/acme-challenge/pK1DYiV5EODCWGWRsV3A2yF67mRaVj0cFG_Dp6Lt4Ng was being saved in my public_html folder. However, that was not my document root - I have everything in a django folder instead. That means the files in the public_html folder weren’t accessible from the web. (I tried creating a test.txt file and could not access it.) I fixed it by going into my drills.enorugby.com.apache2.conf & drills.enorugby.com.apache2-le-ssl.conf files and changing the doc root:

    ServerName drills.enorugby.com

    ServerAdmin info@drills.enorugby.com
    #DocumentRoot /home/admin/web/drills.enorugby.com/django
    DocumentRoot /home/admin/web/drills.enorugby.com/public_html

This allowed me to enable LE support in Vesta. I then changed the files back to the original state and it still works.

I swapped out my staging cert for a production cert, and everything is working now! Thank you for all of your help!


#32

If that file, or any file, is not is use I would delete it (or move it to a completely unrelated folder).

Glad to hear that it is working as you wanted :slight_smile:

Perhaps VestaCP has its’ own idea (setting) of where the document root should be… ? ? ?


closed #33

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