Lets Encrypt not working on just one domain

Discussion in 'Installation/Configuration' started by winsbury, Sep 19, 2019.

  1. winsbury

    winsbury New Member

    Having a weird problem with one domain (let's call it: ispdomain.com ) that refuses to generate a Let's Encrypt certificate for its website

    All the other domains on this server and all work perfectly with the automated Let's Encrypt SSL setting staying ticked and valid certificates issued.

    I suspect the problem is because when I installed Ubuntu 18.04 & ISPconfig 3.1.15 I named the server VPSserver1.ispdomain.com and system mail name mail2.ispdomain.com. The problem is limited to the website [www.]ispdomain.com even though I have checked the basics:

    Client limits:
    SSL available
    Let's Encrypt available

    Website config ticked:
    SSL
    Let's Encrypt SSL


    No matter what I try the certificate never gets created and the Let's Encrypt SSL box unticks itself which I think means there was an error while generating the certificate but I have no idea how to diagnose that any further.

    If I use a manually generated *.ispdomain.com certificate from sslforfree.com by using _acme-challenge DNS TXT records, then https://[www.]ispdomain.com works perfectly but that is not ideal as it will need re-doing every 90 days.

    Another odd thing is if I attach to the server as http://VPSserver1.ispdomain.com I get the default apache page as expected but if I use https://VPSserver1.ispdomain.com I get the certificate and website content from the very first customers website that was created. Also if any other client does not configure their site correctly the https responses also default to the certificate and website from the first website created on the server.

    Have I made some fundamental installation error?
    Can it be fixed without having to rebuild the server from scratch again which would be a nightmare ?
     
  2. ahrasis

    ahrasis Well-Known Member

    Check letsencrypt error log for that domain. Dig it as well, just in case it was pointing to different ip etc.
     
  3. winsbury

    winsbury New Member

    I have checked the log /var/log/letsencrypt/letsencrypt.log but I have no understanding of what it all means. What should I be looking for ?
     
  4. Taleman

    Taleman Well-Known Member HowtoForge Supporter

  5. winsbury

    winsbury New Member

    I've left it plenty long enough to ensure all DNS are updated and tried again at around 1100 UTC to change from a manually generated certificate to a Lets Encrypt automated one. NS A records include VPSserver1.ispdomain.com , ispdomain.com, www.ispdomain.com all pointing to the same IP.

    Note that the main server VPSserver1.ispdomain.com still has its self signed certificate that was created during server installation.

    /etc/letsencrypt/renewal contains three files for ispdomain.com:
    • VPSserver1.ispdomain.com.conf - contains code, this is a hangover from when I tried to add a subdomain while trying to find a workaround
    • ispdomain.com.conf - empty
    • ispdomain.com.conf~backup - contains code

    Extract of the last few lines of the log below, note that these entries are timestamped about 2 hours earlier although I did not make any attempt to make changes at that time. There are no entries in the log for my latest attempt:

    2019-09-19 09:02:23,174:DEBUG:certbot.main:certbot version: 0.23.0
    2019-09-19 09:02:23,175:DEBUG:certbot.main:Arguments: ['-q']
    2019-09-19 09:02:23,175:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
    2019-09-19 09:02:23,182:DEBUG:certbot.log:Root logging level set at 30
    2019-09-19 09:02:23,182:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
    2019-09-19 09:02:23,188:DEBUG:certbot.plugins.selection:Requested authenticator <certbot.cli._Default object at 0x7f1f4d4b9358> and installer <certbot.cli._Default object at 0x7f1f4d4b9358>
    2019-09-19 09:02:23,194:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,196:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,199:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,202:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,204:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,207:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,209:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,212:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,214:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,217:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,218:WARNING:certbot.renewal:renewal config file {} is missing a required file reference
    2019-09-19 09:02:23,218:WARNING:certbot.renewal:Renewal configuration file /etc/letsencrypt/renewal/ispdomain.com.conf is broken. Skipping.
    2019-09-19 09:02:23,219:DEBUG:certbot.renewal:Traceback was:
    Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 60, in _reconstitute
    renewal_candidate = storage.RenewableCert(full_path, config)
    File "/usr/lib/python3/dist-packages/certbot/storage.py", line 415, in __init__
    "file reference".format(self.configfile))
    certbot.errors.CertStorageError: renewal config file {} is missing a required file reference

    2019-09-19 09:02:23,221:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,224:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,226:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,229:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,232:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,234:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,237:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,239:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,242:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,244:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,247:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,249:INFO:certbot.renewal:Cert not yet due for renewal
    2019-09-19 09:02:23,250:DEBUG:certbot.log:Exiting abnormally:
    Traceback (most recent call last):
    File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.23.0', 'console_scripts', 'certbot')()
    File "/usr/lib/python3/dist-packages/certbot/main.py", line 1266, in main
    return config.func(config, plugins)
    File "/usr/lib/python3/dist-packages/certbot/main.py", line 1179, in renew
    renewal.handle_renewal_request(config)
    File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 443, in handle_renewal_request
    len(renew_failures), len(parse_failures)))
    certbot.errors.Error: 0 renew failure(s), 1 parse failure(s)
    At this point the domain is now serving up the certificate and website from client #1 instead of the correct site. I have previously created a 00000-defaultsite.tld as suggested elsewhere in this forum but this never gets served up.

    Putting back the manually created SSL certificate and saving restores the site back to working normally.

    I have tried to dig the domains:
    • VPSserver1.ispdomain.com - correct IP resolves
    • ispdomain.com - correct IP resolves
    • www.ispdomain.com - correct IP resolves
    HOWEVER, if I dig ispdomain.com any , SOMETIMES and not always, the responses are from the old DNS provider including addresses given is for the old server IP. I have now deleted everything from the old DNS servers even though they had no authority anyway and getting consistently the correct responses now. ​
     
    Last edited: Sep 19, 2019
  6. winsbury

    winsbury New Member

    YAY, progress ! ... DNS must have been the cause of the certificate issue in spite of the old DNS having no authority it was still giving out duff info. The log file now shows a successful certificate issuance too. Current status:
    • ispdomain.com - working correctly
    • www.ispdomain.com - working correctly
    • VPSserver1.ispdomain.com still uses the self signed certificate - can this be made to use the new certificate instead?
    There still remains the issue as to why sites default to the 1st customer site in the event of a certificate issue even though I have a 00000-defaultsite.tld set up. -- [SOLVED] it requires the 00000-defaultsite.tld to have a self signed certificate; this overrides the serving up of the 1st client website.
     
    Last edited: Sep 19, 2019
  7. ahrasis

    ahrasis Well-Known Member

  8. winsbury

    winsbury New Member

    Thank you ahrasis; I will give it a go.
    Is it necessary to use it on Postfix Dovecot and pure-FTPd too, don't these already use the client domains own choice of certificate ?
     
  9. ahrasis

    ahrasis Well-Known Member

    It's not but they will not be secured.
    Nope. It is of the server, not client's.
     

Share This Page