[Bug]: Invalid server certificate makes Monal cease to connect

What Monal Release channel are you using?

AppStore

iOS system version

No response

iOS Monal version

No response

macOS system version

13.6

macOS Monal version

6.11

Used XMPP server (domain)

pocnet.net

Which XMPP-Server software are you using?

Prosody

XMPP Server Software Version

0.12.3-1~bpo11+1

How many accounts are you using in Monal?

What happened?

Monal fails to connect to prosody on Debian 12.

I can see the following error in the prosody log file:

Mar 05 00:39:11 c2s55e903ce4db0 info    Client connected
Mar 05 00:39:11 c2s55e903ce4db0 info    Client disconnected: sslv3 alert bad certificate

I found hints about Monal trying to use outdated SSLv3 connections in StoreSpy

After allowing SSLv3 in the prosody configuration, initial Connection succeeds, but fails for other reasons I need to debug first.

Anything else?

I can't do the XEP-Check because the connection failed. Because I can't submit an issue, I ticked XEP-Check checkbox anyway.

Checking the notifications settings, push notifications for my jabber ID are disabled, because the initial connection failed. Because I can't submit an issue, I ticked Notifications-Menu checkbox anyway.

FAQ

[X] I have checked the FAQ for my issue

Considerations for XMPP users

[X] I have checked if my issue can be solved with Considerations for XMPP users and Considerations for XMPP server admins

Related Issues

[X] I have cross-checked this overview https://github.com/monal-im/Monal/issues/322 as well as filtered for related labels https://github.com/monal-im/Monal/labels

XEP-Check

[X] I have checked that at least XEP-198, XEP-0280, XEP-0352, XEP-0357, XEP-0313 and XEP-0163 are activated on my server and shown as 'green' under Settings --> Account--> (i) in advanced settings

Notifications-Menu

[X] I have checked that all checkmarks are present under Settings --> Notifications

No, that's wrong. Openssl reports sslv3 errors because the code handling these errors is the same for all tls versions and was first introduced by the sslv3 implementation. (Furthermore the different protocol parts of TLS use different version numbers, some still being at TLSv1.0 which technically is more or less SSLv3.)

Your error simply means that your certificate isn't trusted and you either used a self-signed one or you did not include all required intermediate certificates. Your store-spy entry is just some misguided user thinking the same after seeing that log entry.

Apps on iOS aren't even allowed to use TLS lower than version 1.2, not even TLSv1.1 is allowed.

Proof of used TLS version: https://github.com/monal-im/Monal/blob/develop/Monal/Classes/MLStream.m#L437

Thanks for your description. Although I think you quickly decided on what I perceive as a wrong conclusion. I'm using the same letsencrypt certificate for many services on the server side and nothing on the client side has shown problems. Besides Monal. I've been using Adium for a long time but it's no longer maintained and shows issues when Apple decides to change underlying API behavior or so.

Also, the configuration in prosody refers to the letsencrypt fullchain.pem, so your assertion about missing intermediates also does not apply.

All in all, your explanation does not cover the fact that by just adding protocol = "sslv3"; to the prosody configuration fixes the described error.

Your certificate IS INVALID. Possibly it is for another domain, expired or otherwise not valid.

If you configure your prosody to use a cert for domain A while prosody is configured to server domain B, you'll get exactly the log message you described initially.

Mar 05 17:17:18 c2s55ef6111b420 debug   Sending[c2s_unauthed]: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Mar 05 17:17:18 conn2q_9ot9BQbTn        debug   Start TLS after write
Mar 05 17:17:18 c2s55ef6111b420 debug   TLS negotiation started for c2s_unauthed...
Mar 05 17:17:18 conn2q_9ot9BQbTn        debug   Prepared to start TLS
Mar 05 17:17:18 conn2q_9ot9BQbTn        debug   Starting TLS now
Mar 05 17:17:19 conn2q_9ot9BQbTn        debug   TLS handshake error: sslv3 alert bad certificate
Mar 05 17:17:19 c2s55ef6111b420 info    Client disconnected: sslv3 alert bad certificate
Mar 05 17:17:19 c2s55ef6111b420 debug   Destroying unbound session for <(unknown)@example.com>: sslv3 alert bad certificate

If you configure sslv3, which is NOT SUPPORTED ANYMORE ON MODERN SYSTEMS, you'll get the following (clearly indicating that you killed your server).

Mar 05 17:19:21 c2s55c1e9473c00 debug   Sent reply <stream:stream> to client
Mar 05 17:19:21 c2s55c1e9473c00 error   No TLS context available for c2s. Earlier error was: invalid protocol (sslv3)
Mar 05 17:19:21 c2s55c1e9473c00 debug   Should be able to do TLS but no context available
Mar 05 17:19:21 c2s55c1e9473c00 debug   Not offering authentication on insecure connection
Mar 05 17:19:21 c2s55c1e9473c00 warn    No stream features to offer on insecure session. Check encryption and security settings.
Mar 05 17:19:21 c2s55c1e9473c00 debug   Disconnecting client, <stream:error> is: <stream:error><undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>No stream features to proceed with</text></stream:error>
Mar 05 17:19:21 c2s55c1e9473c00 debug   Sending[c2s_unauthed]: <stream:error>
Mar 05 17:19:21 c2s55c1e9473c00 debug   Sending[c2s_unauthed]: </stream:stream>
Mar 05 17:19:21 c2s55c1e9473c00 debug   c2s stream for 198.51.100.235 closed: No stream features to proceed with
Mar 05 17:19:21 c2s55c1e9473c00 debug   Destroying unbound session for <(unknown)@example.com>: No stream features to proceed with
Mar 05 17:19:21 connl-y30g2Zh93U        debug   Close after writing remaining buffered data
Mar 05 17:19:21 c2s55c1e9473c00 debug   Discarding data received from resting session: <starttls xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Mar 05 17:19:21 connl-y30g2Zh93U        debug   Closing now

Next time, please be so kind to provide a full POC (configuration) demonstrating your claim.

Thank you for your analyzation.

However, I can't come up with a reason about my certificate being allegedly invalid. So I'm essentially at the point of guesswork.

However, I ask you kindly to look at the issue from my PoV, as I've described above:

you've used an existing server software for "ever since"
you've used an existing client software with this server software "ever since"
you try another client which fails to connect and tries again indefinitely, not providing any error message in the process visible for an ordinary user
you look into the server log to obtain a slight idea what's going wrong
you do some research "fix" the issue and see that the connection progresses further

How would anyone come to believe that the issue described is not within the newly introduced component (Monal)? If the issue were as easy to debug as you assume in your message's subtext I would not have needed to waste your precious time. The complete lack of any error message from Monal is a big contributor to not know what's going wrong.

I assure you there will be no "next time". I perceive your tone as unnecessary harsh and this made me instantly lose any interest in becoming a Monal user.

I appreciate you (and your helpers) efforts to revive XMPP by giving it a modern client. It deserves that. To have a chance above the "modern" bloated completely newly developed chat platforms. Thank you for that.

Your certificate is using leela.pocnet.net as subject/common name (among these ones: bsp-gmbh.pocnet.net, ibmdocs.pocnet.net, kb.pocnet.net, leela.pocnet.net, martinvt.pocnet.net, nc.pocnet.net, tobi.pocnet.net, try-as400.pocnet.net, www.pocnet.net).

Your Prosody is configured to serve pocnet.net.

pocnet.net is NOT among the listed names above.

Adium does connect because you either manually accepted this wrong certificate OR just disabled the certificate check altogether. Or something even more weird/dangerous.

--> Your current setup isn't secure and Monal does not connect because of this --> Monal is right

Monal can't show better error messages because Apple's network framework does not provide any, it just tries to connect indefinitely.

Yes, I'm a bit harsh because doing your research to fix your misconfiguration isn't our business. The original log message clearly stated bad certificate and that's it.

I just found out that your server also hosts leela.pocnet.net. So maybe you just did not remember what you used when setting up Adium and used the wrong domain (pocnet.net) when configuring Monal rather than the right one (leela.pocnet.net)?

Conversations (the XMPP android client won't connect to pocnet.net, too (Error: domain validation failed - that translates to "invalid certificate").

Thank you for your comment and helpful information about my certificate.

When I set up XMPP on different servers many years ago, the documentation I had read hinted towards the certificate's CN has to match the DNS name of the machine to which it connects. This is why leela.pocnet.net is used as CN since this is the primary name of the machine in DNS as well as its hostname. (Other names are mere websites using DNS CNAMEs.)

My DNS zone pocnet.net has no IP address for its domain name (which has become a common habit in the last few years), but appropriate SRV records pointing to the hostname.

_jabber._tcp            IN      SRV     0       0       5269    leela
_xmpp-client._tcp       IN      SRV     0       0       5222    leela
_xmpp-server._tcp       IN      SRV     0       0       5269    leela

This is a bit comparable to SMTP, where the certificate's CN is also meant to match the DNS name and not the domain name prior to MX lookup.

I have assumed (but not verified in the according RFCs, back then) that XMPP is meant to work the same. As it seems, RFC 6125 section 6.2.1 does not support my assumption:

Each reference identifier in the list SHOULD be based on the source domain and SHOULD NOT be based on a derived domain (e.g., a host name or domain name discovered through DNS resolution of the source domain).

However, if I manually configure leela.pocnet.net as the XMPP server host in Monal, the certificate should have been accepted, because my "user input" matches the certificate's CN — as far as I understand the text in section 6.2.1. But Monal did not connect anyways.

Contrary, the IM example paragraph in section 6.2.2 supports my assumption that the XMPP server's DNS name should be used to construct a CN match. Again, if I understand the text correctly.

Apparently Adium behaves to what I initially assumed to be the standard case, and compares a certificate's CN to the final hostname after SRV record lookup is completed. I did no special acceptance or overrides in Adium.

About error messages: It's not my fault that Apple has drawbacks in its networking framework regarding error reporting. Please don't blame me for the incapabilities of Monal to display helpful error messages. I think this is a violation of RFC 6125 section 14.2, whomever fault this is.

I support your PoV that it's not your responsibility to fix my errors. But how am I supposed to learn about a possible misconfiguration without any helpful error messages from Monal? And in turn require to endure your overly harsh reaction to a polite request!

Also I think your attitude of assuming Monal being right in any aspect is neither helpful nor correct. Every program has bugs, this is simple statistics. And RFCs often leave room for interpretation and ambiguity which can result in incompatibilities, as you can learn from my above examples regarding RFC 6125. Programs are made by humans, humans make errors, thus programs have errors. q.e.d.

On the other hand, I hope you can appreciate my time consuming efforts to show you in a polite way where Monal might be wrong, despite it not being my business to make you aware of RFCs to assure interoperability of Monal with edge case configurations you haven't been aware of prior. We live and learn the whole time.

However, if I manually configure leela.pocnet.net as the XMPP server host in Monal, the certificate should have been accepted, because my "user input" matches the certificate's CN — as far as I understand the text in section 6.2.1. But Monal did not connect anyways.

Yes it should and in my tests using your server (leela.pocnet.net) it did. (but obviously I do not have valid credentials, so authentication after establishing the TLS session wasn't possible). I don't know, but maybe you simply made a typo?

Regarding the domain requirement in certs: if the cert domain had to be the one the SRV record is pointing to, man-in-the-middle attacks would be very easy (assuming that no DNSSEC is used): Just spoofing the SRV record to point to any DNS name the attacker has a valid certificate for would be enough.

No, RFC 6215 isn't inconsistent. The example just uses im.example.com for all the different identifiers. The more interesting case is an SRV record on one domain pointing to another domain, but the example in section 6.2.2 only points to itself. That makes it a bad example to showcase the powers of SRV records, but is no inconsistency.

Yes, Monal did not show any helpful error message and that's not your fault. Sure. But your server did and you still chose to ignore it. Based on that I'm not sure if showing some message like "bad certificate" in Monal would have made a difference here.

Yes, I was a bit harsh, but that's because you did not believe me when I told you that your cert is invalid. Even though even your server log said so (and you are not the first one asking for advice but not take it). If you ask a question, then please take the advice, double check everything, and only after that ask again, if you still can't find the problem. But document exactly what you did to double check your setup when you ask again.

Also I think your attitude of assuming Monal being right in any aspect is neither helpful nor correct.

Au contraire, this wasn't an attitude it wasn't even an educated guess. It was simply knowledge. Knowledge isn't an attitude, just as facts aren't just a believe. The only thing I did not know was the exact way your certificate was invalid. (besides that: I never assumed Monal was "right in every aspect", I just said it was right in not accepting your certificate). But even though I knew that it wasn't Monal's fault, I still invested >2 hours to check your case: set up a test server, try out different configs to guess what your server config looks like, check if Monal really doesn't use something lower than TLS 1.2 etc.. That, in addition, I invested substantial time together with Friedrich to reproduce your log messages and proof that your server is misconfigured wasn't even necessary, but I did it nonetheless and even provided the log messages to you.

No, the RFC you cited isn't ambiguous at all, you probably just saw it through the glasses of email deployments where even basic transport encryption using TLS isn't mandatory yet, making MX-records used for man-in-the-middle attacks not the biggest issue. But even for email this is documented:

Let me cite some relevant parts in https://www.postfix.org/TLS_README.html:

In this example, the Postfix SMTP client encrypts all traffic to the example.com domain. The peer hostname is verified, but verification is vulnerable to DNS response forgery.

The Postfix SMTP client will encrypt all traffic and verify the destination name immune from forged DNS responses. MX lookups are still used to find the hostnames of the SMTP servers for example.com, but these hostnames are not used when checking the names in the server certificate(s). Rather, the requirement is that the MX hosts for example.com have trusted certificates with a subject name of example.com or a sub-domain, see the documentation for the smtp_tls_secure_cert_match parameter.

Or over here: https://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_match:

For a description of the pattern and strategy syntax see the smtp_tls_verify_cert_match parameter. The "hostname" strategy should be avoided in this context, as in the absence of a secure global DNS, using the results of MX lookups in certificate verification is not immune to active (man-in-the-middle) attacks on DNS.

You see, your claim (cited below) about SMTP and DNS is not really true either. It's just that SMTP is/was way more insecure, historically seen, and has yet to catch up with modern security measures. It's still in a transition phase to full transport encryption with proper certificate checks (see DANE for example).

This is a bit comparable to SMTP, where the certificate's CN is also meant to match the DNS name and not the domain name prior to MX lookup.

I hope you can appreciate my time consuming efforts to show you where you are wrong ;)

Again, thank you for taking your precious time to reply and try to reconcile. I was not aware of all the testing you did silently in the background. So, take my extra thank-you, please.

A typo when hard coding the server name could not have been the case: Connection tries should have ceased to appear in the Prosody log. I still stay true to my choice to not become a Monal user. I'm not willing to test again. I just want to bring this discussion to an end we both can live with, in a respectful way.

I admire your thinking-ahead about security. But, I'm not sure that it is relevant at large, especially regarding your comparison to SMTP + MX. SMTP is undoubtedly much more widely used than XMPP, and for SMTP the majority "decided" to ignore the described problem, or it's not a problem because DNSSEC being in use. Again, I value your thinking to make it better.

I suggest you to update your FAQ and write some words about the names which must end up in the DNS: or CN attributes in a given certificate. I assert if I would have found such an explanation in the FAQ, this might have made the penny drop for me. As such, I did not merely ignore your advice but not understand why my certificate is invalid just for Monal and nothing else I've been using so far.

To make Monal work with my setup, I would (at least) need to tweak my DNS zone so the domain itself has an IP address. This is necessary for Letsencrypt to do its work. I'm appalled against doing so. A domain IMO has hosts and sometimes subdomains but an IP address? It feels wrong to me. It is my subjective and personal choice to not do so.

As I understand from your arguments, Monal will always check the domain component of the XMPP contact as stated in RFC 6125 section 6.2.1 to compare to the CN, while obviously Adium does not. My refusal to do as everyone else does in terms of DNS configuration means, I can't (easily) add the domain part to the certificate to make Monal work. In addition, I'd prefer to have my email address and XMPP contact equal, so using poc@leela.pocnet.net isn't adequate from my PoV. I'm deliberately stuck here and will leave it be.

You might think about introducing a configuration option to allow indirect certificates (after SRV resolution), but that's entirely up to you. Since my zone is DNSSSEC protected, I'd be fine with that, security-wise.

About error messages: Please try to look at it from my PoV: A working setup with Adium and Prosody fails to work by introducing Monal as a new client. The server says Client disconnected: sslv3 alert bad certificate, which appeared to me completely illogical:

If the server's certificate were invalid, why does it work with Adium and other clients for other TLS protected services?
Does Monal present some kind of certificate Prosody is not able to handle?
Why is sslv3 involved?

It just didn't occur to me that Prosody might forward a client generated string to the log! How could an average sysadmin know that "sslv3" is a mere descriptive string in this context? Only after your explanations before I was able to guess that the error message in the prosody log is actually sent from Monal to prosody and ends up in the log! Would Monal have presented this very same error string, I'm pretty sure, I would never had to bother you. After this lengthy discussion I admit that I probably should have recognized that Prosody might forward a client generated string to the log with just "Client disconnected" stating the following string is actually a message from the client itself. I apologize for not seeing this due to the heated nature of this initial exchange.

Your statement my certificate is invalid and immediate closure of this issue definitely contributed to my perception of your conclusion being premature and your overall reaction and tone not being appropriate (initially):

the certificate is used for other services on the host without issue
Adium works without issue

In addition, while the error message "sslv3 alert bad certificate" is probably correct, it was still not helpful. What property of the certificate is invalid? Not everybody is an expert in certificate handling. I admire Safari and Adium which allow you to inspect certificates with the OS built-in standard dialog, which also outputs a text which hints about why a certificate is deemed invalid. This includes mismatches of CN and URL strings in Safari. Monal has not shown such a helpful tool. Again, if error reporting was more comprehensible for the average XMPP server admin, I would never had to bother you. Also, see my suggestion about introducing a new topic into the FAQ.

Please don't blame me for the lack of comprehensible error reporting in Monal (on macOS). As a user I don't care if this is due to a drawback of some OS provided framework or a bug or a missing feature elsewhere.

Again, thank you for taking your time. I assert, it's not wasted entirely, because I have learned some things and probably you also gained some experience.

Okay, some final words:

Well, if you want to use pocnet.net as domain for xmpp you need a certificate for pocnet.net. If you don't like to have a IP address at pocnet.net (something most websites do today in addition to providing the www subdomain), you can use the DNS challenge provided by letsencrypt.

As such, I did not merely ignore your advice but not understand why my certificate is invalid just for Monal and nothing else I've been using so far.

Well, but you did not write something like "I don't understand this, why does it work with Adium then?". If you've written something like this, I would have asked you if you deactivated the strict certificate checking in Adium next, instead of assuming that you just ignored my advice.

My refusal to do as everyone else does in terms of DNS configuration means, I can't (easily) add the domain part to the certificate to make Monal work.

You might get a problem with server-to-server communication in the future when servers start to validate the certificate of your server more strictly, too.

Prosody does not forward a client specified string, it outputs an error message generated by openssl when it receives a TLS protocol alert-type message having the "invalid certificate" codepoint set. But well, the logging in Prosody could be better. Something like "TLS connection with client failed, got client alert: sslv3 alert bad certificate"

[...] and your overall reaction and tone not being appropriate (initially):

Well, you are not the first one asking questions like that when simply having an invalid certificate (any type of invalid). It always costs time to explain the same things over and over again and most of these users don't (unlike you) read the wiki at all. That's why I reacted that harsh (thinking that you are one of these users not reading the wiki and not getting basic things right, I'm sorry about that!).

Somehow apple's network framework is now able to report errors again.

Release 6.3.0 (pending apple review) will bring better messages for cert failures (albeit not that specific, but at least it displays a cert error at all).

monal-im / Monal