Hello, everyone!
This is my first post on these forums as we are giving Metabase OSS a try, getting to know it and check its possibilities. So far we are very happy with what we are seeing!
Unfortunately, today I had the brilliant idea of upgrading Metabase from version 0.45.3 to version 0.46.0 and now I am seeing this error in the log file:
WARN server.HttpChannel :: handleException / org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
I presume that embedded Jetty Webserver must have been switched to enforcing SNI (jetty.ssl.sniRequired=true). The thing is that I thought that I had my Java KeyStore properly configured, which contains just a wildcard certificate (with the internal domain of the cluster, which is different from the public domain set up on NGINX, which acts as a reverse proxy):
# keytool -list -v -keystore keystore.jks
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: internaldomain.com
Creation date: Apr 4, 2023
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=internaldomain.com
Issuer: CN=R3, O=Let's Encrypt, C=US
Serial number: 476c498fec6c6006b8b9a3a0d3f51850187
Valid from: Fri Mar 17 23:03:11 UTC 2023 until: Thu Jun 15 23:03:10 UTC 2023
Certificate fingerprints:
SHA1: A2:6D:C1:08:FA:C0:62:61:4C:E8:C5:34:E7:29:36:28:F9:18:BF:B1
SHA256: 6C:58:AE:E3:6D:C9:E4:CC:81:E0:4C:43:B3:A5:D3:9B:B7:26:84:A7:CF:C4:E0:44:AB:2C:87:07:C8:40:5D:94
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 256-bit EC (secp256r1) key
Version: 3
Extensions:
#1: ObjectId: 1.3.6.1.4.1.11129.2.4.2 Criticality=false
0000: [..]
[..]
00F0: [..]
#2: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
[
accessMethod: ocsp
accessLocation: URIName: http://r3.o.lencr.org
,
accessMethod: caIssuers
accessLocation: URIName: http://r3.i.lencr.org/
]
]
#3: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: [..]
0010: [..]
]
]
#4: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]
#5: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [2.23.140.1.2.1]
[] ]
[CertificatePolicyId: [1.3.6.1.4.1.44947.1.1.1]
[PolicyQualifierInfo: [
qualifierID: 1.3.6.1.5.5.7.2.1
qualifier: 0000: [..] sencrypt.org
]] ]
]
#6: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
serverAuth
clientAuth
]
#7: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
]
#8: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: *.internaldomain.com
DNSName: internaldomain.com
]
#9: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 0F A2 27 61 3A 09 AD 40 34 12 21 03 E8 18 81 4E ..'a:..@4.!....N
0010: 7D 66 4F B8 .fO.
]
]
*******************************************
*******************************************
This is how the NGINX 1.18 is configured:
upstream metabase {
server metabase1.internaldomain.com:8080 fail_timeout=10s max_fails=1;
keepalive 100;
keepalive_requests 1000;
keepalive_timeout 75s;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name metabase.publicdomain.com;
ssl_certificate /etc/ssl/certs/publicdomain.com.crt;
ssl_certificate_key /etc/ssl/private/publicdomain.com.key;
ssl_trusted_certificate /etc/ssl/chains/andronautic.com.chn;
include inc/ssl-options.conf;
resolver 192.168.0.253 192.168.0.254 ipv6=off;
[.. logfiles ..]
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header Host $http_host;
proxy_set_header Connection "keep-alive";
proxy_set_header Early-Data $ssl_early_data;
proxy_http_version 1.1;
proxy_redirect off;
proxy_ssl_session_reuse on;
proxy_ssl_protocols TLSv1.2 TLSv1.3;
proxy_ssl_trusted_certificate /etc/ssl/certs/ISRG_Root_X1.pem;
proxy_pass https://metabase;
}
}
This is the system info as seen on the Metabase logfile:
metabase1 metabase[6970]: {"file.encoding" "UTF-8",
metabase1 metabase[6970]: "java.runtime.name" "OpenJDK Runtime Environment",
metabase1 metabase[6970]: "java.runtime.version" "11.0.18+10-post-Debian-1deb11u1",
metabase1 metabase[6970]: "java.vendor" "Debian",
metabase1 metabase[6970]: "java.vendor.url" "https://tracker.debian.org/openjdk-11",
metabase1 metabase[6970]: "java.version" "11.0.18",
metabase1 metabase[6970]: "java.vm.name" "OpenJDK 64-Bit Server VM",
metabase1 metabase[6970]: "java.vm.version" "11.0.18+10-post-Debian-1deb11u1",
metabase1 metabase[6970]: "os.name" "Linux",
metabase1 metabase[6970]: "os.version" "5.15.104-1-pve"
I have checked the environment variables document looking for some sort of MB_JETTY_SSL_SNI option but I have not been able to find it. Not that it would be a good solution for a wanna-be production environment, but at least would give me more time (downgrading to 0.45.3 does not seem to be an option due to changes in the database schema).
So, questions would be:
- Can anyone point out what is not right in my Java KeyStore?
- Alternatively, can anyone instruct me on how to prevent Jetty from checking SNI?
Thanks in advance. Keep up the good work on this product!
