ISPConfig & Let's Encrypt: certificate generates ok but 'SSL' & 'Let's Encrypt SSL' become unchecked

Discussion in 'ISPConfig 3 Priority Support' started by Etcetera, Apr 11, 2019.

  1. Etcetera

    Etcetera New Member HowtoForge Supporter

    Hello,

    recently, I have observed intermittent failures trying to enable SSL for new websites with Let's Encrypt in ISPConfig 3.1.13 on a Ubuntu 16.04 LTS server (set up according to the Ubuntu 16.04 with Apache, PHP, MySQL, PureFTPD, BIND, Postfix, Dovecot and ISPConfig 3.1 variant of the 'Perfect Server' docs).

    I've had one or two issues recently with websites created in the style 'domain.tld' plus 'www' as auto subdomain, for which only a certificate for 'www.domain.tld' was created, not for 'domain.tld', while both the "SSL" and "Let's Encrypt" checkboxes stayed checked.

    Now I seem out of luck with one such website, which I tried to break up into the 'www' website (plus the 'domain.tld' one as forward-only) which didn't work, either, I had to revert it to plain http for the time being.

    When I check "SSL" and "Let's Encrypt SSL" and save it, the certificate is generated ok and placed in the directory in which it belongs, but when I reopen the ISPConfig page for the website, "SSL" and "Let's Encrypt SSL" are unchecked and trying to access the site via https fails.

    I see only one anomaly reported in letsencrypt.log, which is a note saying "Error during a POST-as-GET request" and "Invalid Content-Type header on POST. Content-Type must be "application/jose+json", biut then it continues with "Retrying request with GET", which obviously finishes ok:

    Code:
    [...]
    
    2019-04-11 21:37:11,686:DEBUG:acme.client:Received response:
    HTTP 415
    Server: nginx
    Content-Type: application/problem+json
    Content-Length: 168
    Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
    Replay-Nonce: K-cxd5uz1KtJDPk4xqn6lyuw0Xq5YUBXoaRMTzsP-gQ
    Expires: Thu, 11 Apr 2019 19:37:11 GMT
    Cache-Control: max-age=0, no-cache, no-store
    Pragma: no-cache
    Date: Thu, 11 Apr 2019 19:37:11 GMT
    Connection: close
    
    {
      "type": "urn:ietf:params:acme:error:malformed",
      "detail": "Invalid Content-Type header on POST. Content-Type must be \"application/jose+json\"",
      "status": 415
    }
    2019-04-11 21:37:11,687:DEBUG:acme.client:Error during a POST-as-GET request, your ACME CA may not support it:
    urn:ietf:params:acme:error:malformed :: The request message was malformed :: Invalid Content-Type header on POST. Content-Type must be "application/jose+json"
    2019-04-11 21:37:11,687:DEBUG:acme.client:Retrying request with GET.
    
    [...]
    
    2019-04-11 21:37:11,998:DEBUG:certbot.reporter:Reporting to user: Congratulations! Your certificate and chain have been saved at [...]
    Your key file has been saved at [...]
    
    The "invalid content-type header" thing seems to be connected to the issue in https://github.com/letsencrypt/boulder/issues/3529, but as the retry via GET worked, I guess it shouldn't actually be the problem here?

    Any ideas on how to go on from here?

    Thanks in advance,
    Etc
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

  3. Etcetera

    Etcetera New Member HowtoForge Supporter

    Excellent. Updating ISPConfig to git-stable solved it. Thanks a lot!
    Cheers, Etc
     

Share This Page