Reputation: 1402
On my local machine, the mail is setup as recommended by SES's official documentation, and works like a charm. The app works exactly the same on my EC2 deployment as well. EXCEPT for the mail part. Whenever I send an email on my production app, I get the errors below:
Error 1/2
ClientException in RequestException.php line 107:
Client error: `POST https://email.eu-west-1.amazonaws.com` resulted in a `403 Forbidden` response:
<ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>InvalidClie (truncated...)
and 2/2
SesException in WrappedHttpHandler.php line 192:
Error executing "SendRawEmail" on "https://email.eu-west-1.amazonaws.com"; AWS HTTP error: Client error: `POST https://email.eu-west-1.amazonaws.com` resulted in a `403 Forbidden` response:
<ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>InvalidClie (truncated...)
InvalidClientTokenId (client): The security token included in the request is invalid. - <ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>InvalidClientTokenId</Code>
<Message>The security token included in the request is invalid.</Message>
</Error>
<RequestId>0a137c9c-5fd9-11e6-a886-973129052803</RequestId>
</ErrorResponse>
The .env
file for my production is setup with the database linked to my EC2. It works fine with all other aspects of the application. Composer is updated with all dependencies updates. I use SMTP to send mails via SES to a verified domain. The IAM role on my EC2 is the default EC2 role made when creating the Amazon Linux AMI. There is an SES role as well. The security group allows all TCP outbound traffic.
Upvotes: 2
Views: 11022
Reputation: 5256
Mine is even more ridiculous. I'm using VirtualBox and its clock was off by a few minutes (my laptop went to sleep at some point before) and that caused the signature to mismatch. Restarting the virtual machine did it.
Upvotes: 2
Reputation: 3682
I hit this issue on Laravel 8 and tried everything. Turns out, quoting the .env
values causes the issue. Removing double quotes from the values solved my problem.
Bad
MY_SECRET="secret_aws_key_420"
Good
MY_SECRET=secret_aws_key_420
This is curious because quotes were introduced as a means of ensuring encoding issues like this one wouldn't occur.
Package versions for reference:
Upvotes: 1
Reputation: 61
I was also facing this issue and had eaten up a few hours of mine. The solution is simple. Do not use the SMTP credential as your username and password. Instead, go to IAM, create a new user and add SES permission. Then try again !!!
Upvotes: 6
Reputation: 1402
Okay, solved it. The root access keys that I have put into services.php
were inactive. I created a new root keys file, replaced the keys in the services.php
and it solved the problem.
Upvotes: 4