Originally created by @voidnecron on GitHub (Nov 6, 2017).
Hi,
I've recently updated my pfSense 2.3 to the new branch. And as with all good things something MUST break down, LetsEncrypt/Dehydrated seems to be the Darwin victim... :)
See error below. This is a brand new git clone.
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
If you need any testing or additional logs let me know.
Cheers!
VN
Originally created by @voidnecron on GitHub (Nov 6, 2017).
Hi,
I've recently updated my pfSense 2.3 to the new branch. And as with all good things something MUST break down, LetsEncrypt/Dehydrated seems to be the Darwin victim... :)
See error below. This is a brand new git clone.
[2.4.1-RELEASE][admin@pfSense]/usr/local/src/dehydrated: ./dehydrated -c -d mydomain.com -d webmail.mydomain.com -d fw.mydomain.com -d autodiscover.mydomain.com -d domoticz.mydomain.com
# INFO: Using main config file /etc/dehydrated/config
Processing mydomain.com with alternative names: webmail.mydomain.com fw.mydomain.com autodiscover.mydomain.com domoticz.mydomain.com
+ Signing domains...
+ Creating new directory /etc/dehydrated/certs/mydomain.com ...
+ Creating chain cache directory /etc/dehydrated/chains
+ 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
If you need any testing or additional logs let me know.
Cheers!
VN
Sorry, but you might want to take a look at this too. (redmine I've filed for this issue @ pfsense). https://redmine.pfsense.org/issues/8059
It was the openssl.cnf file which got broken, however check out the number two comment from Jim.
@voidnecron commented on GitHub (Nov 8, 2017):
Sorry, but you might want to take a look at this too. (redmine I've filed for this issue @ pfsense).
https://redmine.pfsense.org/issues/8059
It was the openssl.cnf file which got broken, however check out the number two comment from Jim.
Having read the comment indicated on redmine... it seems like the issue causing concern isn't the certificate or CSR generated by dehydrated (via OpenSSL), but the potential for other OpenSSL commands to return errors when being run from the command line.
But the reason for this is that they set prompt=no in openssl.cnf. Otherwise, OpenSSL would prompt for valid information to fill out the fields in the certificate. I don't know why they've set prompt=no in their version of openssl.cnf (they probably have their reasons), but that isn't required for dehydrated's sake.
(For reference, my openssl.cnf doesn't contain the prompt field at all [which defaults to prompt=yes], and it works perfectly well with dehydrated.)
@txr13 commented on GitHub (Nov 8, 2017):
Having read the comment indicated on redmine... it seems like the issue causing concern isn't the certificate or CSR generated by dehydrated (via OpenSSL), but the potential for other OpenSSL commands to return errors when being run from the command line.
But the reason for this is that they set `prompt=no` in openssl.cnf. Otherwise, OpenSSL would prompt for valid information to fill out the fields in the certificate. I don't know _why_ they've set `prompt=no` in their version of openssl.cnf (they probably have their reasons), but that isn't required for dehydrated's sake.
(For reference, my openssl.cnf doesn't contain the prompt field at all [which defaults to `prompt=yes`], and it works perfectly well with dehydrated.)
I've looked into that bug, and the only way to prevent this from happening in the future would be to use a completely new openssl config file instead of basing it on the system one... since it also varies from release to release this seems like a bad idea.
There is a config option to set a custom openssl config, so if this should happen again you could easily copy the config, make the changes manually, place it in a new path and tell dehydrated where to find it.
@lukas2511 commented on GitHub (Dec 5, 2017):
So I see this issue has been resolved, great :)
I've looked into that bug, and the only way to prevent this from happening in the future would be to use a completely new openssl config file instead of basing it on the system one... since it also varies from release to release this seems like a bad idea.
There is a config option to set a custom openssl config, so if this should happen again you could easily copy the config, make the changes manually, place it in a new path and tell dehydrated where to find it.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @voidnecron on GitHub (Nov 6, 2017).
Hi,
I've recently updated my pfSense 2.3 to the new branch. And as with all good things something MUST break down, LetsEncrypt/Dehydrated seems to be the Darwin victim... :)
See error below. This is a brand new git clone.
[2.4.1-RELEASE][admin@pfSense]/usr/local/src/dehydrated: ./dehydrated -c -d mydomain.com -d webmail.mydomain.com -d fw.mydomain.com -d autodiscover.mydomain.com -d domoticz.mydomain.com
INFO: Using main config file /etc/dehydrated/config
Processing mydomain.com with alternative names: webmail.mydomain.com fw.mydomain.com autodiscover.mydomain.com domoticz.mydomain.com
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
If you need any testing or additional logs let me know.
Cheers!
VN
@w194 commented on GitHub (Nov 7, 2017):
could you tell your openssl version
@voidnecron commented on GitHub (Nov 8, 2017):
Hi @widder
It's the default version of pfSense 2.4.1:
OpenSSL 1.0.2k-freebsd 26 Jan 2017
@w194 commented on GitHub (Nov 8, 2017):
ok thanks. i try to reproduce it asap. i also plan using dehydated on my freebsd machines soon
@voidnecron commented on GitHub (Nov 8, 2017):
Sorry, but you might want to take a look at this too. (redmine I've filed for this issue @ pfsense).
https://redmine.pfsense.org/issues/8059
It was the openssl.cnf file which got broken, however check out the number two comment from Jim.
@txr13 commented on GitHub (Nov 8, 2017):
Having read the comment indicated on redmine... it seems like the issue causing concern isn't the certificate or CSR generated by dehydrated (via OpenSSL), but the potential for other OpenSSL commands to return errors when being run from the command line.
But the reason for this is that they set
prompt=noin openssl.cnf. Otherwise, OpenSSL would prompt for valid information to fill out the fields in the certificate. I don't know why they've setprompt=noin their version of openssl.cnf (they probably have their reasons), but that isn't required for dehydrated's sake.(For reference, my openssl.cnf doesn't contain the prompt field at all [which defaults to
prompt=yes], and it works perfectly well with dehydrated.)@lukas2511 commented on GitHub (Dec 5, 2017):
So I see this issue has been resolved, great :)
I've looked into that bug, and the only way to prevent this from happening in the future would be to use a completely new openssl config file instead of basing it on the system one... since it also varies from release to release this seems like a bad idea.
There is a config option to set a custom openssl config, so if this should happen again you could easily copy the config, make the changes manually, place it in a new path and tell dehydrated where to find it.