IP-1.5 error sending email using SMTP (PHP 7.0)

Support
1

I was using IP-1.4.10 using php 5.5 before I upgraded to IP-1.5 using php 7.0.

When I try to send an email I get the following errors:

browser error message:
It seems that the application stuck because of an error.

THEN:

This site can’t be reached

The web page at https://.co.uk/index.php/mailer/send_invoice/130 might be temporarily down or it may have moved permanently to a new web address.
ERR_SPDY_PROTOCOL_ERROR

/application/logs:
https://paste.invoiceplane.com/view/ddaa948f

I tried changing to php 5.6, BUT I am still not able to send any emails; and have created a separate post for that issue…

Thanks

David

2

Please search on Google before posting a support thread as this is an error related to Google Chrome and not InvoicePlane.

3

Thanks Kovah, although the 2nd part of the error is related to Google Chrome, I think the first part of the error IS related to invoiceplane.

Please forget about:

and can you look into the problem and have a look at the logs I posted at https://paste.invoiceplane.com/view/ddaa948f

Thanks

5

clearing the browsing cache can be helpful. I have tried and it really work
see this guide: http://errorcodespro.com/how-to-fix-chromes-err_spdy_protocol_error/

6

If you want to get full Guide then visit here to get best way to fix spdy protocol error on chrome

7

@Kovah I think there is an issue with the SMTP connection to the mail server. Logs following…

Scenario 1

IP 1.5.4 - PHP7 - Mozilla Firefox - IP runs on Server1 and email server runs on Server2
System Settings > Email > Email Sending Method: SMTP
System Settings > Email > Security SSL
System Settings > Email > Verify SMTP certificates: Yes

Client approves quote, system tries to send email, browser not stuck, email NOT sent!
Log at Email Server [Server2]:
2017-10-12 16:58:58 TLS error on connection from Server1 [1.2.3.4] (gnutls_handshake): An unexpected TLS packet was received.

Scenario 2

IP 1.5.4 - PHP7 - Mozilla Firefox - IP runs on Server1 and email server runs on Server2
System Settings > Email > Email Sending Method: SMTP
System Settings > Email > Security TLS
System Settings > Email > Verify SMTP certificates: Yes

Client approves quote, system tries to send email, browser stuck for some time and then Connection timed out error at browser, email NOT sent!
Log at Email Server [Server2]:
2017-10-12 16:46:20 TLS error on connection from Server1 [1.2.3.4] (gnutls_handshake): An unexpected TLS packet was received.

I can reproduce those issues 100% of the times. It seems that something was changed in the TLS/SSL handshake part that is causing these issues.

Please note that in my case (at least) I can’t use PHPmail or Sendmail, so in essence there is no email functionality :frowning:

Message me or quote me in this thread if you want me to perform more tests.

8

Running some more tests it seems that the only combination that works is:

  • System Settings > Email > Security = SSL
  • System Settings > Email > Verify SMTP certificates = No

Please note that the email server has a valid certificate, so this looks like a bug.

@dfear could you please try with the above settings and let us know if this workaround works for you as well?

9

I will check that. May be a bug which may be already solved with a newer version of PhpMailer.

10

Hi

This combination works for me too.

11

its all happening just because of bug. just remove it by beta testing.

12

Hi,

Are you using “localhost” as your SMTP serve namer in InvoicePlane? If so, that’s why you need to change the "Verify SMTP Certificates" to no. If you are not using an FQDN for the mail server name, a TLS error occurs when the certificates are checked (localhost != host.domain.com). This is causes a gnutls_handshake error. If you want to verify TLS certificates, the common name must match the connected hostname. It isn’t a bug, that’s how TLS Veritifcation works.

The same thing occurs with a web site, eg. ‘mysite.domain.com’ when you access it by IP address. You get an “untrusted certificate” warning, even though the certificate is valid.

d

13

Hi @twoup and thanks for the reply.

This is not the problem in my case, in which the mail server runs on a different machine. And to clarify a bit more, I’m accessing the mail server (SMTP settings) using FQDN. The mail server has both Forward and Reverse DNS lookup name and the certificate matches this name ofc.

There is chance though for something else, which I didn’t have the time to check yet. If the server’s certificate chain is not complete (i.e. doesn’t have the intermediate certificate from the CA), IP might not be able to verify the whole chain up to the CA.

If someone wants to verify the certificate chain of their mail servers, here is a tip:
https://www.sslshopper.com/ssl-checker.html#hostname=[SERVER-NAME-HERE]:465
If you see a broken chain, that might be the pitfall.

Let me know of your thoughts.

14

That seems likely, as that would also cause a gnutls verification failure. Unfortunately, the sensibility of the debug output from gnutls doesn’t match the verbosity!

In reality, if you’re using authenticated SMTP and you control both hosts, your chain of trust isn’t as important is it would be when using a third party’s server. You know you can trust the server you’re connecting to. Obviously, however, this could be a problem for other servers connecting to your host as the level of security increases across the world.

15

I can confirm that -in my case at least- the problem was with incomplete certificate chain on the mail server.

I have a test installation of IP, so I spent some time just to test this. After completing the certificate chain on the mail server, the problem disappeared :smile:

2 Likes