ejabberd: How to use "ldap_tls_certfile" - ejabberd

According to the ejabberd docs, you can use ldap_tls_certfile in order to verify the TLS connection to the LDAP server. But which certificate is expected here?
Quoting the docs:
A path to a file containing PEM encoded certificate along with PEM
encoded private key. This certificate will be provided by ejabberd
when TLS enabled for LDAP connections. There is no default value,
which means no client certificate will be sent.
Sooo.... I tried to use a concatenated PEM file containing first the host certificate of the ejabberd server, then second the host key. But this leads to the following errors:
<0.471.0>#eldap:connect_bind:1073 LDAP connection to
ldap1.example.com:636 failed: received CLIENT ALERT: Fatal - Handshake
Failure - {bad_cert,hostname_check_failed}
<0.1975.0> TLS client: In state certify at ssl_handshake.erl:1372 generated CLIENT ALERT: Fatal - Handshake Failure - {bad_cert,hostname_check_failed}
This obviously is not what is expected. Is it the public certificate of the LDAP server? But then, what private key is expected?
I'm a bit lost here. Anyone mind to lend me a hand?

Disclaimer: I never used LDAP TLS.
Looking at the ejabberd source code, the value of ejabberd's option ldap_tls_certfile
is copied into eldap's option tls_certfile
https://github.com/processone/ejabberd/blob/e4d600729396a8539e48ac0cbd97ea1b210941cd/include/eldap.hrl#L72
And later the value of eldap's tls_certfile is copied into ssl's option certfile
https://github.com/processone/ejabberd/blob/e4d600729396a8539e48ac0cbd97ea1b210941cd/src/eldap.erl#L580
That option, among others, is provided as an argument when calling ssl:connect/4
https://github.com/processone/ejabberd/blob/e4d600729396a8539e48ac0cbd97ea1b210941cd/src/eldap.erl#L1140
So, the option that you set in ejabberd is named 'certfile' in ssl:connect, you can see here its documentation:
https://erlang.org/doc/man/ssl.html#connect-4
Searching for certfile in that page, it shows this description:
Path to a file containing the user certificate on PEM format.
Is it the public certificate of the LDAP server?
Try that one and comment here.
But then, what private key is expected?
Try not putting any private key. In any case, when the LDAP certificate was created, it produced a private key file, too.

Related

What are the new requirements for certificates in Chrome?

Chrome now throws NET::ERR_CERT_INVALID for some certificates that are supported by other browsers.
The only clue I can find is in this list of questions about the new Chrome Root Store that is also blocking enterprise CA installations.
https://chromium.googlesource.com/chromium/src/+/main/net/data/ssl/chrome_root_store/faq.md
In particular,
The Chrome Certificate Verifier will apply standard processing to include checking:
the certificate's key usage and extended key usage are consistent with TLS use-cases.
the certificate validity period is not in the past or future.
key sizes and algorithms are of known and acceptable quality.
whether mismatched or unknown signature algorithms are included.
that the certificate does not chain to or through a blocked CA.
conformance with RFC 5280.
I verified my certificates work as expected in Edge.
Further, I verified the certificate is version "3", has a 2048-bit key, and has the extended key usage for server authentication.
I still don't understand which "standard" this certificate is expected to conform to when the browser only says "invalid". Is there a simple template or policy I can use?
Chrome now rejects TLS certificates containing a variable known as pathLenConstraint or sometimes displayed as Path Length Constraint.
I was using certificates issued by Microsoft Active Directory Certificate Services. The Basic Constraints extension was enabled, and the AD CS incorrectly injects the Path length Constraint=0 for end entity, non-CA certificates in this configuration.
The solution is to issue certificates without Basic Constraints. Chrome is equally happy with Basic Constraints on or off, so long as the path length variable is not present.
One of the better resources for troubleshooting was this Certificate Linter:
https://crt.sh/lintcert
It found several errors in the server certificate, including the path length set to zero.
I also found a thread discussing a variety of Certificate Authorities that would issue certificates the same way, so it is a fairly common issue.
https://github.com/pyca/cryptography/issues/3856
Another good resource was the smallstep open source project that I installed as an alternative CA. After generating a generic certificate, the invalid cert error went away and I realized there was something going on between the Microsoft and Google programs.
The best favour you can do yourself is to run Chrome with debug logging to find the exact cause of the issue:
chrome --enable-logging --v=1
This, I believe, will print:
ERROR: Target certificate looks like a CA but does not set all CA properties
Meanwhile it seems they have reverted this verification, which if I'm not mistaken will be released as Chrome 111 in the beginning of March.
See: https://chromium-review.googlesource.com/c/chromium/src/+/4119124
Following #Robert's answer, I used https://crt.sh/lintcert to fix all the issues that I had, so my self-signed certificate will keep on working, as it suddenly stopped working and I got NET::ERR_CERT_INVALID
Here's How I did it:
# https://www.openssl.org/docs/manmaster/man5/x509v3_config.html
cat > "$_X509V3_CONFIG_PATH" << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=critical,CA:true
keyUsage=critical,digitalSignature,nonRepudiation,cRLSign,keyCertSign
subjectAltName=#alt_names
issuerAltName=issuer:copy
subjectKeyIdentifier=hash
[alt_names]
DNS.1=somesubdomain.mydomain.com.test
EOF
openssl x509 -req \
-days "$_ROOTCA_CERT_EXPIRE_DAYS" \
-in "$_ROOTCA_PEM_PATH" \
-signkey "$_ROOTCA_KEY_PATH" \
-extfile "$_X509V3_CONFIG_PATH" \ # <--- Consuming the extensions file
-out "$_DOMAIN_CRT_PATH"
Following the above, my lint errors/issues are, and even though there's a single ERROR, my Chrome browser trusts the root CA and the self-signed certificate
cablint WARNING CA certificates should not include subject alternative names
cablint INFO CA certificate identified
x509lint ERROR AKID without a key identifier
x509lint INFO Checking as root CA certificate
For those of you who wish to generate a self-signed certificate for local development with HTTPS, the following gist does that trick- https://gist.github.com/unfor19/37d6240c35945b5523c77b8aa3f6eca0
Usage:
curl -L --output generate_self_signed_ca_certificate.sh https://gist.githubusercontent.com/unfor19/37d6240c35945b5523c77b8aa3f6eca0/raw/07aaa1035469f1e705fd74d4cf7f45062a23c523/generate_self_signed_ca_certificate.sh && \
chmod +x generate_self_signed_ca_certificate.sh
./generate_self_signed_ca_certificate.sh somesubdomain.mydomain.com
# Will automatically create a self-signed certificate for `somesubdomain.mydomain.com.test`

Google cloud function - trying 2 way ssl handshake but getting error unable to find valid certification path to requested target

I have my own clients Private key and certificate which I have put in keystore, and servers public certificate root and intermediate I have created truststore and put them into it. I am trying to ssl handshake but not able to do so. I have below code snippet not sure what went wrong
KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
KeyStore keystore = KeyStore.getInstance("JKS");
keystore.load(keystoreStream, "mypass".toCharArray());
kmf.init(keystore, "mypass".toCharArray());
KeyManager[] keyManagers = kmf.getKeyManagers();
keystoreStream.close();
keystoreStream = null;
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
KeyStore truststore = KeyStore.getInstance("JKS");
truststore.load(truststoreStream, "mypass".toCharArray());
tmf.init(truststore);
TrustManager[] trustManagers = tmf.getTrustManagers();
truststoreStream.close();
truststoreStream = null;
SSLContext sslContext = SSLContext.getInstance("SSL");
sslContext.init(keyManagers, trustManagers, null);
if (urlConnection instanceof HttpsURLConnection) {
HttpsURLConnection httpURLConnection = (HttpsURLConnection) urlConnection;
httpURLConnection.setRequestMethod("POST");
httpURLConnection.setSSLSocketFactory(sslContext.getSocketFactory());
//error on below line
httpURLConnection.connect();
OutputStreamWriter wr = new OutputStreamWriter(urlConnection.getOutputStream());
wr.write(requestData.toString());
wr.flush();
responseCode = httpURLConnection.getResponseCode();
}
}
Error -
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The problem is caused by a certificate that is self-signed (a Certificate Authority did not sign it) or a certificate chain that does not exist within the Java truststore.
As a workaround, you can add this certificate to the list of trusted certificates of your JVM.
First you can check if your certificate is already in the truststore
by running the following command: keytool -list -keystore "$JAVA_HOME/jre/lib/security/cacerts" (you don't need to provide a
password).
If your certificate is missing, you can get it by downloading it with
your browser and add it to the truststore with the following command:
keytool -import -noprompt -trustcacerts -alias <AliasName> -file <certificate> -keystore <KeystoreFile> -storepass <Password>
Alternatively you may refer to this thread.
It is important that you see that the correct truststore is in use.
If -Djavax.net.ssl.trustStore has been configured, it will override
the location of the default truststore, which will need to be
checked.
Also,you may have multiple JRE/JDKs and that sometimes might be a
source of confusion. Hence, make sure the certificates have been
imported into the correct truststore.
Check if your Anti Virus tool has "SSL Scanning" blocking SSL/TLS. If
it does, disable this feature or set exceptions for the target
addresses.
Verify that the target server is configured to serve SSL correctly.
This can be done with the SSL Server Test tool.
If the above fails, your truststore might be out of date. Upgrade
Java to the latest version supported by your application.

GAS MySQL SSL connection

I want to connect via Jdbc.getConnection() with my Google Cloud MySQL db and use SSL.
Within GAS: I have made the exact same setup as described in this old answer, but I get the error message: "Exception: We're sorry, a server error occurred. Please wait a bit and try again."
conn = Jdbc.getConnection('jdbc:mysql://xxx.xxx.xxx.xxx/myDBname?useSSL=true', {
'user': settings.user,
'password': settings.userPwd,
'_serverSslCertificate': '-----BEGIN CERTIFICATE-----super_secret_1-----END CERTIFICATE-----',
'_clientSslCertificate': '-----BEGIN CERTIFICATE-----super_secret_2-----END CERTIFICATE-----',
'_clientSslKey': '-----BEGIN RSA PRIVATE KEY-----super_secret_3-----END RSA PRIVATE KEY-----'
});
Did something change over the years?
What I have tried so far:
The user and password seems to be correct, because without "?useSSL=true" everything works
I have also created new SSL certificates within GCP
Unfortunately Jdbc.getCloudSqlConnection() is not an option to use instead Jdbc.getConnection()
Runtime V8 and Stable/Rhino throw the same error
Cause for the issue: Within the certificate and key strings the "\n" are missing.
These are not inserted within the GCP SQL modal when a new SSL certificate was created. So you need to download client-key.pem, client-cert.pem and server-ca.pem and replace each line break with a "\n".

SSL messages encoding

I am trying to build an SSL Server under Python 3.4. The point is to communicate and exchange data with a programme through a defined protocol based on JSON data format.
So I used a basic "echo server" and client in SSL Protocol and modified those to see if I could exchange data. It worked and sending "hello" one side comes as b"hello" on the other side and it works both ways.
I start the server side, connect the program, it communicates succesfully, but:
I am expecting something like : LOGIN:n::{“user”:”XXXXX”, , ”password”:”YYYYY ”, app”:”ZZZZZ”, “app_ver”:”zzz”, ”protocol”:”xxx”,”protocol_ver”:”xxxx”} arriving from the client (program)
But instead I am getting something like this b"\x16\x03\x03\x00\x8e\x01\x00\x00\x8a\x03\x03^\x9e\xeb\xd8\x8f\xd9 \x05v\xbbF:}\xda\x17\xf7\x13\xff\xa9\xde=5\xfb_\xbco\x16\x96EL#\x00\x00*\xc0,\xc0+\xc00\xc0/\x00\x9f\x00\x9e\xc0$\xc0#\xc0(\xc0'\xc0\n\xc0\t\xc0\x14\xc0\x13\x00\x9d\x00\x9c\x00=\x00<\x005\x00/\x00\n\x01\x00\x007\x00\n\x00\x08\x00\x06\x00\x1d\x00\x17\x00\x18\x00\x0b\x00\x02\x01\x00\x00\r\x00\x14\x00\x12\x06\x01\x06\x03\x04\x01\x05\x01\x02\x01\x04\x03\x05\x03\x02\x03\x02\x02\x00#\x00\x00\x00\x17\x00\x00\xff\x01\x00\x01\x00"
I thought it was simply encoded, but I have tried the bytemessage.decode()method, with utf-8, cp437, cp1250, cp1252, latin-1, etc. I have also tried codecs.decode() with hex. No success, I Don't understand what language is this.
I am new to SSL so I suppose I am missing something obvious here, but I have no idea what …
Any help would be greatly appreciated.
Thanks in advance !
---- Edit here is the code of my server-----
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_address = ('localhost', 5000)
print ('starting up on %s port %s' % server_address)
sock.bind(server_address)
sock.listen(1)
while True:
print ( 'waiting for a connection')
connection, client_address = sock.accept();
try:
print( 'connection from', client_address)
while True:
data = connection.recv(16)
print ( 'received "%s"' % data)
if True:
#data2=b'{"timing":{"liveEvents": {"sector": {"dayTime": 1483523892618,"driver": 1,"isValid": false,"participant": "0","sector": 3,"time": -1}}}}'
print ('sending data to the client')
#connection.sendall(data2)
else:
print ( 'no more data from', client_address)
break
finally:
connection.close()
b"\x16\x03\x03...
This is a TLS message. Looks like your client tries to speak TLS to your server but your server cannot properly handle it. Instead of treating the data as TLS it will assume that the TLS is the actual application data.
Looking at your server code the reason is clear: you are not doing any SSL there, i.e. you are doing a plain TCP socket. SSL will not magically appear just because a clients tries to talk SSL with the server but you need to use the ssl module, properly wrap_socket and provide the necessary server certificate and key. For some simple example see the documentation.
As #Steffen mentioned , I wasn't handling SSL at all, which I now do with ssl.wrap_socket(sock,certfile='certificat.pem', keyfile='cle.pem', server_side=True)
Operation on server side requires certificates and key files in pem, which I generated with SelfSSL7 and then split the pfx into 2 pem key and certificate files with OpenSSL
openssl pkcs12 -in yourpfxfile.pfx -nocerts -out privatekey.pem -nodes
openssl pkcs12 -in yourpfxfile.pfx -nokeys -out publiccert.pem -nodes
Maybe not the fastest solution for a self signed certificate since I now have OpenSSL installed but …
Finally, the expected message !!
starting up on localhost port 11000
waiting for a connection
connection from ('127.0.0.1', 60488)
received "b'PING:0::\r\n'"
sending data to the client
received "b'LOGIN:::{"user":"test","password":"test","app":"AppName","app_ver":"1.0.0","protocol":" ","protocol_ver":"1.0.0"}\r\n'"
sending data to the client
Again thank you very much #SteffenUllrich

How to Support SSL in Airflow MySQLHook (in particular AWS 2019CA)

I have been using MySQLHook happily in my Airflow DAG but now the MySQL server (AWS RDS) will have SSL connection mandatory. My backend engineer told me that in particular AWS 2019 CA should be used. I looked into the MySQLHook documentation and found the following snippet from https://airflow.readthedocs.io/en/stable/_modules/airflow/hooks/mysql_hook.html:
if conn.extra_dejson.get('ssl', False):
# SSL parameter for MySQL has to be a dictionary and in case
# of extra/dejson we can get string if extra is passed via
# URL parameters
dejson_ssl = conn.extra_dejson['ssl']
if isinstance(dejson_ssl, six.string_types):
dejson_ssl = json.loads(dejson_ssl)
conn_config['ssl'] = dejson_ssl
It looks like I need to specify some configuration in the form of JSON ("SSL" key) in the extra section of the MySQL connection in Airflow but I couldn't find any examples of this. Can someone enlighten me? Any pointer or an example of such JSON would be very appreciated.
Your Connection.extra data should be a JSON string containing a ssl object suitable for passing to the mysql_ssl_set function, according to the "Functions and attributes" section on this page:
This parameter takes a dictionary or mapping, where the keys are parameter names used by the mysql_ssl_set MySQL C API call. If this is set, it initiates an SSL connection to the server; if there is no SSL support in the client, an exception is raised. This must be a keyword parameter.
Presumably something like this would work: {"ssl": {"cert": "PATH TO YOUR PUBLIC CERT FILE ON THE AIRFLOW SERVER"}}