Thanks for making a fantastic piece of software, I’m a huge fan.
I am having the same problem. I’m using a Digital Ocean Droplet and recently updated my instance to 4.1.0, but the problem was also happening on 4.0.1.
I have set the mailgun API key both in the admin UI and also in production config file. I have also forced using SSL in mailgun API settings. I restarted the app after updating settings.
{
“name”: “Log”,
“hostname”: “nazdalniaku-newsletter”,
“pid”: 8817,
“level”: 50,
“err”: {
“id”: “31512e90-88ee-11eb-baa3-c3a17c117235”,
“domain”: “…”,
“code”: “ERR_SSL_WRONG_VERSION_NUMBER”,
“name”: “EmailError”,
“statusCode”: 500,
“level”: “normal”,
“message”: “Failed to send email. Reason: 140296814708608:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:…/deps/openssl/openssl/ssl/record/ssl3_record.c:332:\n.”,
“help”: “"Please see Configuration - Adapt your publication to suit your needs for instructions on configuring email."”,
“stack”: “EmailError: Failed to send email. Reason: 140296814708608:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:…/deps/openssl/openssl/ssl/record/ssl3_record.c:332:\n.\n at EmailError.GhostError (/var/www/ghost/versions/4.1.0/node_modules/@tryghost/errors/lib/errors.js:10:26)\n at new EmailError (/var/www/ghost/versions/4.1.0/node_modules/@tryghost/errors/lib/errors.js:34:20)\n at createMailError (/var/www/ghost/versions/4.1.0/core/server/services/mail/GhostMailer.js:52:12)\n at MailComposer.returnCallback (/var/www/ghost/versions/4.1.0/core/server/services/mail/GhostMailer.js:95:28)\n at SMTPConnectionPool._onConnectionError (/var/www/ghost/versions/4.1.0/node_modules/simplesmtp/lib/pool.js:334:17)\n at SMTPClient.emit (events.js:315:20)\n at SMTPClient.EventEmitter.emit (domain.js:482:12)\n at SMTPClient._onError (/var/www/ghost/versions/4.1.0/node_modules/simplesmtp/lib/client.js:373:10)\n at TLSSocket.emit (events.js:315:20)\n at TLSSocket.EventEmitter.emit (domain.js:482:12)\n at emitErrorNT (internal/streams/destroy.js:92:8)\n at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)\n at processTicksAndRejections (internal/process/task_queues.js:84:21)\n\nError: 140296814708608:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:…/deps/openssl/openssl/ssl/record/ssl3_record.c:332:\n”
},
“msg”: “Failed to send email. Reason: 140296814708608:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:…/deps/openssl/openssl/ssl/record/ssl3_record.c:332:\n.”,
“time”: “2021-03-19T20:03:37.596Z”,
“v”: 0
}
I’m encountering the same issue. Is there an alternative to removing “secureConnection”: true," from the config file? Perhaps a setting somewhere in Mailgun?
@nbomberger Thank you. But does the value need to be false? Is there a way to enable the secure connection? I’m not exactly what the benefit/s of doing so are, but I assume there are some?
It will use a secure connection. Make sure the port is 587, which will trigger (SSL,TLS).
This is a bug in my opinion and a horribly documented solution, but you should be secure.
Totally weird, right? This is my understanding at least.
@nbomberger Sorry Nathaniel, something still isn’t clear to me. If we want it to be secure, we need to make sure the port is 587 and use:
"secure": true,
Is that right? And could you explain what the bug is? (Unless it’s an exploitable bug, in which case please don’t explain it here on the public forum, of course.)
IF YOU WANT IT TO WORK SET IT TO secure false and port 587. Ignore what seems logical and do it. all done and you are good. Ignore the logic and just do it. Go ahead and test it to see that port 587 uses SSL/TLS.
"secure": true - opens a connection immediately with SSL, this is failing in some cases because the default ciphers that connection is opened with are not compatible with the service that you’re connecting to
"secure": false - opens a non-secure connection then uses TLS to negotiate a valid cipher before switching to a secure connection to complete the email sending. Typically you’ll need to use port 587 for this as it’s the standard port for secure TLS connections, some providers may vary though
It’s important to note that both options are secure. There is no “bug”, just standard configuration options.