Project

General

Profile

Actions
Copy link

Bug #8059

closed

/etc/ssl/openssl.cnf in 2.4.0 and 2.4.1 is broken

Added by Anonymous about 7 years ago. Updated about 7 years ago.

Status:
Resolved
Priority:
Very Low
Assignee:
Jim Pingle
Category:
Certificates
Target version:
2.4.2
Start date:
11/06/2017
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.x
Affected Architecture:

Description

When using dehydrated (https://github.com/lukas2511/dehydrated) instead of the acme package for requesting LetsEncrypt certificates (because it works with localdir without having to install HAProxy..) it uses /etc/ssl/openssl.cnf.
Every update the commonName is being reset, but that's a 'known issue'.
However, since 2.4.0 the file has been change so much it generates an error when signing the request:

[2.4.1-RELEASE][]/usr/local/src/letsencrypt.sh: ./dehydrated -x -c -d fw.domain.com -d webmail.domain.com -d autodiscover.domain.com
  1. !! WARNING !! No main config file found, using default config! #
    Processing domain.com with alternative names: webmail.domain.com autodiscover.domain.com
    + Checking domain name(s) of existing cert... unchanged.
    + Checking expire date of existing cert...
    + Valid till Dec 21 09:01:00 2017 GMT (Longer than 30 days). Ignoring because renew was forced!
    + Signing domains...
    + Generating private key...
    + Generating signing request...
    problems making Certificate Request
    34380751816:error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long:/builder/ce-241/tmp/FreeBSD-src/crypto/openssl/crypto/asn1/a_mbstr.c:158:maxsize=2

When I'm using https://github.com/pfsense/pfsense/blob/RELENG_2_3_5/src/etc/ssl/openssl.cnf instead of the 2.4.0 or 2.4.1 version it works:

[2.4.1-RELEASE][]/usr/local/src/dehydrated: ./dehydrated -c -d domain.com -d webmail.domain.com -d fw.domain.com -d autodiscover.domain.com
  1. INFO: Using main config file /etc/dehydrated/config
    Processing domain.com with alternative names: webmail.domain.com fw.domain.com autodiscover.domain.com
    + Signing domains...
    + Generating private key...
    + Generating signing request...
    + Requesting challenge for domain.com...
    + Requesting challenge for webmail.domain.com...
    + Requesting challenge for fw.domain.com...
    + Requesting challenge for autodiscover.domain.com...

It has something to do with "countryName_default" which is outcommented in the 2.3.5 version, but not in the newer.
Just commenting it out doesn't work.

Actions
Copy link
 #1

Updated by Jim Pingle about 7 years ago

  • Assignee set to Jim Pingle
  • Category set to Certificates
  • Status changed from New to Confirmed
  • Priority changed from Normal to Very Low
  • Target version set to 2.4.2
  • Affected Version set to 2.4.x

It is not broken, it works fine when you use it in a supported way (read: use the GUI or the ACME package).

Nonetheless, I'll look into it. There are some differences there, but I'll have to check on why those changes were made.

Actions
Copy link
 #2

Updated by Jim Pingle about 7 years ago

I just pushed a fix for this, but a few important points need to be made:

1. The ACME package works fine serving from a local webroot without haproxy. Whatever you read about requiring haproxy was wrong. But exposing your firewall's web server to the Internet is an awful idea. Using 'standalone' mode in ACME will fire up a service only when needed, which is better, but still not ideal. That may also be what dehydrated does but I'm not familiar with that client. Still, it's entirely unnecessary to use it when the ACME package will work properly and hook into the GUI and other places naturally.
2. Generating a certificate in the way that caused the original error will undoubtedly have filled the CSR with bunk info (a generic city/state/company/etc), which may be ignored by ACME when they sign your certificate, but could cause problems for anyone using openssl at the CLI directly using the default configuration file.

Actions
Copy link
 #3

Updated by Jim Pingle about 7 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #4

Updated by Anonymous about 7 years ago

Jim Pingle wrote:

Applied in changeset 3414dea15b2f31099ef2ec962c2062ae95080a0e.

Hi Jim,

Thanks for the fix!
1) I'll look into the local webroot part again, but I couldn't get it to work in the first run (invalid response issue). What I do is during the certificate request open the firewall port for the http check and disable the port 80 rule once the request/validation was completed. I'm aware of the risk but thanks for pointing it out.
2) Could be. I'll make sure the creator of dehydrated reads this redmine to make sure his software doesn't fsck things up as well.

Again, thanks for the time to fix this!

Cheers

Actions
Copy link
 #5

Updated by Jim Pingle about 7 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link

Also available in: Atom PDF