Sonarqube cannot get SMTP mails to work

Hey folks.

Using Sonarqube 9.9.3, from a ZIP, behind an Nginx proxy.

We are trying to set it up to send emails, but it fails spectacularly for some reason.

Tried both via the WebUI and via the sonar.properties
Getting Configuration invalid: please double check SMTP host, port, login and password. on Send Test Mail.
Absolutely nothing shows up in the web.log and sonar.log.

Configuration is as follows:

email.smtp_host.secured=localhost
email.smtp_port.secured=587
#email.smtp_secure_connection.secured=true
email.smtp_secure_connection.secured=starttls
email.smtp_username.secured=
email.smtp_password.secured=
email.fromName=SonarQube
email.from=no-reply@<redacted>
email.prefix=[SONARQUBE]

We have a local Postfix setup, with SMTPS and Submission enabled for it. The configuration works for ALL other services that use it on various machines. Sending with mailx from the VM itself also works. So its not Postfix issue.

Tried with both 25,465 and 587, starttls or none.
Makes no difference.

The documentation at Notifications in SonarQube is SUPER plain, with absolutely nothing mentioned there.

Hi,

Welcome to the community!

You might want to bump up (temporarily!) the logging level.

Also, what shows up in your SMTP server logging?

 
Ann

Hello,

Setting debug verbosity shows some info on both sides. Fails at handshake.

org.apache.commons.mail.EmailException: Sending the email to the following server failed : localhost:587```
```Caused by: javax.mail.MessagingException: Could not convert socket to TLS
	at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:2155)
	at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:752)
	at javax.mail.Service.connect(Service.java:388)
	at javax.mail.Service.connect(Service.java:246)
	at javax.mail.Service.connect(Service.java:195)
	at javax.mail.Transport.send0(Transport.java:254)
	at javax.mail.Transport.send(Transport.java:124)
	at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1459)
	... 147 common frames omitted
Caused by: java.io.IOException: Can't verify identity of server: localhost
	at com.sun.mail.util.SocketFetcher.checkServerIdentity(SocketFetcher.java:697)
	at com.sun.mail.util.SocketFetcher.configureSSLSocket(SocketFetcher.java:634)
	at com.sun.mail.util.SocketFetcher.startTLS(SocketFetcher.java:553)
	at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:2150)
	... 154 common frames omitted

This is regardless of used method.
Quick google shows the following:

But adding it to the java_opts for the web runner or a separate line does nothing, same error.

Postfix logs:

Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: connect from localhost[127.0.0.1]
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: setting up TLS connection from localhost[127.0.0.1]
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: localhost[127.0.0.1]: TLS cipher list "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:before SSL initialization
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:before SSL initialization
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:SSLv3/TLS read client hello
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:SSLv3/TLS write server hello
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:SSLv3/TLS write change cipher spec
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:TLSv1.3 write encrypted extensions
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:SSLv3/TLS write certificate
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:TLSv1.3 write server certificate verify
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:SSLv3/TLS write finished
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:TLSv1.3 early data
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:TLSv1.3 early data
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:SSLv3/TLS read finished
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: localhost[127.0.0.1]: Issuing session ticket, key expiration: 1708966802
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL_accept:SSLv3/TLS write session ticket
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: SSL3 alert read:warning:user canceled
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: lost connection after CONNECT from localhost[127.0.0.1]
Feb 26 18:30:03 sonarqube postfix/smtps/smtpd[550788]: disconnect from localhost[127.0.0.1] commands=0/0

The postfix says the client (ie, Sonarqube) cancelled the connection.

Hi,

I did some searching of my own. You succeeded better than I did at finding something that matched the error you’re getting. Nonetheless, I doubt what’s needed here is a program-level change (updating the spring.mail properties). Why? Because if that were necessary, we’d be seeing this complaint a lot more often and yours is the first time I can remember seeing this particular problem with mail. (And there aren’t a lot of threads about SMTP configuration overall.)

Is your mail server’s certificate self-signed? Still valid? Imported into the trust store of the JVM running SonarQube?

 
Ann

We are not using self-signed certificates.
Postfix is set to use Lets Encrypt wildcard certificate. The FROM FQDN matches the certificate wildcard.
Yes, its valid.
As for being in the trust store… The CA is being part of the OS ca-certificates (and thus accessible by Java). It should be able to do a Chain Lookup.
If i need to explicitly add it to a trust/key store, mind if you give me more information?

PS: I see that we SonarQube has the previously mentioned property set to true.
But i believe this is not configurable, since it lacks a “configuration” to it.

Hi,

Here’s the top result on that.

 
HTH,
Ann

Setting in the hosts file for 127.0.0.1 to point to the machine FQDN and then using as smtp_host the FQDN, resolves the issue.
Which points that the issue is indeed caused by email.setSSLCheckServerIdentity(true);
Unfortunately, i cant even build the source of branch-9.9 or the latest 9.9.4 tag, because it seems like there is something broken with dependency URLs pointing to Artifactory that does not work.

I cant change the java class files as well, since the needed part is garbled.

Setting mail.smtp.ssl.trust to localhost does nothing as well, since its probably ignored by JVM (as the rest of the related properties that i tried).

Pointing 127.0.0.1 to the FQDN in the hosts file is not desirable, since some things actually rely on the actual DNS record to point to something else than the loopback interface.

I would suggest to add a configuration option for email.setSSLCheckServerIdentity();, where we can manually override the default true value.

It would help in this particular use case, where a local MTA (Postfix) uses a valid certificate, but the connection to it is going though a loopback interface - since otherwise that would mean you need to have the MTA bind on non-loopback interfaces, so you can actually match the certificate CN with the smtp_host.
Or allow use of mail.smtp.ssl.trust, so we can explicitly trust localhost.

For the record, i tried all of those extra runtime arguments:
-Dmail.smtp.ssl.trust=localhost -Dmail.smtp.ssl.checkserveridentity=false -Dmail.smtp.ssl.enable=true -Dmail.smtp.localaddress=localhost
the SNI one gets ignored because its already set in the code, the rest… no idea why.

Hi,

Thanks for the detailed reporting on your deep investigation.

Since the workaround you’ve found is sub-optimal, I’m going to pass this on to the team.

 
Ann

1 Like