Hi everybody I have been setting up remote access to node-red for my raspberry Pi. I have amended the settings.js and installed node-red-admin but when I go to start node-red I get the following error:
Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
at Object.createSecureContext (_tls_common.js:131:17)
at Server.setSecureContext (_tls_wrap.js:1152:27)
at Server (_tls_wrap.js:1030:8)
at new Server (https.js:65:14)
at Object.createServer (https.js:89:10)
at Object.<anonymous> (/usr/lib/node_modules/node-red/red.js:141:20)
at Module._compile (internal/modules/cjs/loader.js:945:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:962:10)
at Module.load (internal/modules/cjs/loader.js:798:32)
at Function.Module._load (internal/modules/cjs/loader.js:711:12) {
library: 'SSL routines',
function: 'SSL_CTX_use_certificate',
reason: 'ee key too small',
code: 'ERR_SSL_EE_KEY_TOO_SMALL'
}
nodered.service: Main process exited, code=exited, status=1/FAILURE
nodered.service: Failed with result 'exit-code'.
nodered.service: Service RestartSec=100ms expired, scheduling restart.
nodered.service: Scheduled restart job, restart counter is at 1.
Stopped Node-RED graphical event wiring tool.
Started Node-RED graphical event wiring tool.
_tls_common.js:131
c.context.setCert(cert);
This happened after I successfully created privatekey.pem and certificate.pem. To create these files I used:
openssl genrsa -out privatekey.pem 1024
then used
openssl req -new -key privatekey.pem -out private-csr.pem
after which I put in relevant info and then recieved verification «signature is ok» with
openssl x509 -req -days 365 -in private-csr.pem -signkey privatekey.pem -out certificate.pem
As the above returned privatekey.pem and certificate.pem files under ls -la I moved onto uncommented the following:
// The `https` setting requires the `fs` module. Uncomment the
following
// to make it available:
var fs = require("fs");
module.exports = {
// the tcp port that the Node-RED web server is listening on
uiPort: process.env.PORT || 1880,
and also
adminAuth: {
type: "credentials",
users: [
{
username: "admin",
password: "$2a$08$9Miva2AQEFlXQ3S7emXlIuLkLzNzi9yzgqxGYMY5dzK4FzNQa7dCu",
permissions: "*"
}
]
},
with loading fs module
https: {
key: fs.readFileSync('/home/pi/.node-red/privatekey.pem'),
cert: fs.readFileSync('/home/pi/.node-red/certificate.pem')
},
After doing this configuration I get the error message stated at the beginning.
Update: I did delete the contents of .node-red/settings.js and replaced with https://github.com/node-red/node-red/blob/master/packages/node_modules/node-red/settings.js
and node-red starts! woohoo!
However when try to reconfigure the settings.js file again it runs into the same error..
FYI I am carefully uncommenting lines however could the problem reside in the hash-pw i receive from node-red-admin? Because when I try to install node-red-admin with «npm install -g node-red-admin» after logging in as root via «su» it comes up with the following:
pi@padrejuan:~ $ su
Password:
root@padrejuan:/home/pi# npm install -g node-red-admin
/usr/local/bin/node-red-admin -> /usr/local/lib/node_modules/node-red-
admin/node-red-admin.js
> bcrypt@3.0.6 install /usr/local/lib/node_modules/node-red-
admin/node_modules/bcrypt
> node-pre-gyp install --fallback-to-build
node-pre-gyp WARN Using request for node-pre-gyp https download
node-pre-gyp WARN Pre-built binaries not installable for bcrypt@3.0.6
and node@12.11.1 (node-v72 ABI, glibc) (falling back to source compile
with node-gyp)
node-pre-gyp WARN Hit error EACCES: permission denied, mkdir
'/usr/local/lib/node_modules/node-red-admin/node_modules/bcrypt/lib'
gyp WARN EACCES user "nobody" does not have permission to access the
dev dir "/root/.cache/node-gyp/12.11.1"
gyp WARN EACCES attempting to reinstall using temporary dev dir
"/usr/local/lib/node_modules/node-red-admin/node_modules/bcrypt/.node-
gyp"
gyp WARN install got an error, rolling back install
gyp WARN install got an error, rolling back install
gyp ERR! configure error
and so on.
Any help would be greatly appreciated
Upgraded my server to 20.04. Now I can’t get IMAP working through dovecot. I get:
Aug 1 23:25:53 defaria dovecot: imap-login: Error: Failed to initialize SSL server context: Can't load SSL certificate: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small: user=<>, rip=184.182.63.133, lip=208.113.131.137, session=<iKgXGN+rCIC4tj+F>
I found many solutions to this problem but none seem to work. I’ve generated and re-generated server keys, signing certificates, and the like and configured dovecot to look at them yet all I get is this cryptic error message. I had this all configured nicely before and just updating from 18.04 -> 20.04 broke this.
How can I fix this? Step by step… How to I supposed generate a cert and a key and properly configure them into dovecot so that imap works again?
Funny thing is I can drive a session through telnet to imap and I can log in an access messages. But when I try to do the same with my mail client (thunderbird) I get the above error written to /var/log/mail.log
Zanna♦
68.3k55 gold badges210 silver badges320 bronze badges
asked Aug 2, 2020 at 6:37
Andrew DeFariaAndrew DeFaria
3601 gold badge3 silver badges11 bronze badges
I needed to add the following to my /etc/dovecot/conf.d/10-ssl.conf file:
ssl_dh = </usr/share/dovecot/dh.pem
The dh.pem file did already exist in my case, but YMMV.
answered Oct 14, 2020 at 19:05
None of these solutions worked for me, as the /usr/share/dovecot/dh.pem already existed and was the required 4096 bit.
Turns out the solution was as simple as deleting the /var/lib/dovecot/ssl-parameters.dat file, then restarting dovecot using:
sudo systemctl restart dovecot
answered Dec 27, 2021 at 1:48
3
The answer to this is that your dh.pem file does not have enough bits.
Ubuntu provides one in /etc/dovecot and /usr/share/dovecot. The later of the two directories has one of enough bits (4096).
I think (not tested for now) that you can also generate your own dh.pem file with the following command:
openssl dhparam -out dh.pem 4096
Then simply add the line:
ssl_dh=</your/dir/here/dh.pem
To /etc/dovecot/conf.d/10-ssl.conf
(including the < character before the /)
Zanna♦
68.3k55 gold badges210 silver badges320 bronze badges
answered Oct 1, 2021 at 22:32
$ curl -s https://goolge.ca | wc
0 0 0
$ curl -vs https://goolge.ca
. . .
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, bad certificate (554):
* SSL certificate problem: EE certificate key too weak
* Closing connection 0
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Why this EE certificate key too weak problem?
I found a similiar problem,
https://serverfault.com/questions/1033354/how-to-diagnose-ca-certificate-too-weak-error-how-to-use-the-ca-cert-anyway
but that one is CA certificate key too weak, I don’t know if it the same as EE certificate key too weak.
asked Apr 7, 2021 at 20:55
By default, Debian has configured OpenSSL at security level 2, which provides 112 bits of security. That means that if one of the keys involved in the TLS connection, in this case the server’s key (the end-entity certificate), provides a security level less than 112 bits (usually because the certificate is an RSA key smaller than 2048 bits), then it will be rejected.
Since a 112 bit security level is even below the recommended 128-bit minimum these days and this server is below even that, the best thing to do is to contact the server administrator and ask them to generate a new TLS certificate. With such an insecure certificate, a major corporation or a government could probably crack the key with some effort, and consequently spoof the connection.
If you can’t do that, you can lower the security level by using curl --ciphers DEFAULT@SECLEVEL=1. Note that by doing this, you’re essentially accepting that your connection is not completely secure and is subject to tampering.
answered Apr 8, 2021 at 2:00
bk2204bk2204
2,2861 gold badge5 silver badges6 bronze badges
3
That is interesting, the manual insist on mentioning TLS, and it might be in generic meaning as Transport Security Layer, because looking at your log file, the first packet has 19 byte size and this can’t be a ClientHello message record for TLS, as at least a random with 32 byte should be included !
So here 2 points to check
1) That module doesn’t have TLS, mean it will use pre shared key for direct encryption/decryption using the algorithms mentioned in the documentation
Quote
AES: AES encryption, CBC method，TCP/UDP all support this.
DES3: DES3 encryption, TCP/UDP all support this.
Input key: AES or DES3 key. For AES encryption, the key is fixed 16 bytes length, the IV value is the same as key. For DES3 encryption, the key is fixed 24 bytes length, the IV value the first 8 Bytes of key. The key can be ASCII or Hex format data. Hex format data need to use “space” character as separator, ex, “01 02 03…”
But here i have difficulty understanding the lack of mentioning of what padding is been used, combine this with the fact first packet was 19 bytes, on other hand this might work if the size of the packet is defined and fixed as 3+n*16 which will start to make sense, but you first need to capture one packet ( the first one with 19 bytes ) and paste it here to see what is inside, will be better if you repeated it and confirmed it is still the same, then change the key on that module ( only the key not the algorithm) and capture another packet to compare them, and do the same for second algorithm 3DES, is there a third option in that security box in Sock group, AES , 3DES .. ?? (TLS may be, if not then TLS is not supported on that module)
2) the module does support TLS somehow, but in this case it will be using the PSK cipher suites, i looked at ICS source and i see that the default is all PSK ciphers are disabled, here Angus can help if that is possible to enable them and how, i have no idea.
the ciphers that might be working should be some of those, (all of these doesn’t need certificates)
// likely to work
0x00,0x8B TLS_PSK_WITH_3DES_EDE_CBC_SHA Y N [RFC4279]
0x00,0x8C TLS_PSK_WITH_AES_128_CBC_SHA Y N [RFC4279]
// very unlikely to be supported
0x00,0x90 TLS_DHE_PSK_WITH_AES_128_CBC_SHA Y N [RFC4279]
0x00,0x94 TLS_RSA_PSK_WITH_AES_128_CBC_SHA Y N [RFC4279]
0x00,0xAE TLS_PSK_WITH_AES_128_CBC_SHA256 Y N [RFC5487]
0x00,0xB2 TLS_DHE_PSK_WITH_AES_128_CBC_SHA256 Y N [RFC5487]
0x00,0xB6 TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 Y N [RFC5487]
0xC0,0x35 TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA Y N [RFC5489]
0xC0,0x37 TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256 Y N [RFC5489]
cipher lists from here https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
Anyway if first case is how it does data been sent then your server doesn’t need OpenSSL at all, the second will will need a confirmation from Agnus on how to test it.