AWS CLI SSL Validation Failed: The Certificate Error and Its 5 Causes
Here's the direct answer: "SSL validation failed... [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed" almost never means AWS's certificate is broken. It means the AWS CLI doesn't trust whatever sits between your computer and AWS — most often a corporate proxy, antivirus software, or a misconfigured certificate setting on your own machine. The fix is nearly always local, not something wrong on Amazon's end, and in most cases it takes one command to confirm the cause and one setting to correct it.
Jake got this one on a Tuesday morning. He runs a small phone repair and resale shop, and last year he started backing up his repair intake photos and receipts to an S3 bucket every night with a scheduled aws s3 sync command, so a stolen laptop or a dead hard drive wouldn't wipe out three years of paperwork. That morning the sync job failed silently overnight, and when he ran the command by hand to see why, this is what he got.
He assumed he'd broken something in AWS. He hadn't touched his AWS account in months. Nothing about his bucket had changed. What had changed, it turned out, was that the shop's new antivirus software — installed by the IT contractor who does his point-of-sale system — had quietly started inspecting outbound HTTPS traffic the week before.
What "SSL validation failed" is actually telling you
Every time the AWS CLI talks to an AWS service, it opens an HTTPS connection and checks the certificate the other end presents. That check has two parts: is the certificate signed by an authority the CLI trusts, and does the certificate's name match the address it's connecting to. When either check fails, the CLI refuses the connection and raises this error instead of quietly sending your data somewhere unverified. That refusal is a safety feature working correctly — it's just surfacing a trust problem, not necessarily a broken one.
🙋♂️ Jake's Reality Check
"So did I mess up my AWS account, or not?"
No. This error happens before the CLI even gets to check your permissions or your bucket. It's a handshake problem, not an account problem — nothing about your IAM setup or your S3 bucket caused it.
The AWS CLI itself lists three specific triggers for exactly this error text: your traffic is passing through a proxy whose certificate the CLI doesn't recognize, your CA bundle setting is pointing at the wrong location, or your AWS Region setting is wrong and the CLI is hitting an endpoint it wasn't expecting to talk to. We'll add two more that show up constantly in practice — a broken CLI installation and an outdated TLS stack — and walk through the exact command for each.
Read the error text carefully — the wording tells you the cause
Before you try anything, look at what comes after "certificate verify failed" in your error message. The exact wording narrows down which of the five causes you're dealing with, and it saves you from trying fixes that don't apply to your situation.
| What follows "certificate verify failed" | Most likely cause | Jump to fix |
|---|---|---|
| self signed certificate in certificate chain | A proxy or security tool is re-signing your traffic | Cause 1 |
| unable to get local issuer certificate | Same as above, or a broken CLI install | Cause 1 or Cause 3 |
| [Errno 2] No such file or directory | Your ca_bundle setting points at a file that doesn't exist | Cause 2 |
| nothing extra, just the SSL line, on a command that used to work | Wrong Region set, or Region setting missing | Cause 4 |
| EOF occurred in violation of protocol, or an UNSAFE_LEGACY_RENEGOTIATION line | Old CLI version or old OS TLS support | Cause 5 |
Cause 1: something is intercepting your HTTPS traffic and re-signing it
This is the cause behind most of these errors, by a wide margin. Many offices, schools, and some antivirus or endpoint-security products inspect outgoing HTTPS traffic for security reasons. To do that, the proxy or security software sits in the middle of the connection: it terminates your HTTPS session, inspects the traffic, then re-encrypts it and forwards it on, signing the new connection with its own certificate — one your company generated itself, not one issued by a public certificate authority.
🙋♂️ Jake's Reality Check
"Why does my browser not throw a fit about this, then? I use the same wifi to check my email all day."
Because someone already told your browser to trust it. Ethan puts it this way: "Think of a certificate authority as a notary. Your browser has a list of notaries it trusts by default, and when your company set up your laptop, they quietly added their own notary to that list — probably through a policy pushed out by whatever manages your machine. The AWS CLI keeps its own, separate list of trusted notaries, and nobody added your company's to it. So the browser shrugs and moves on, and the CLI stops cold."
That's the whole mechanism: a "certificate authority" is just an entity everyone agrees to trust to vouch for other certificates, and a "chain of trust" is the sequence of vouching that runs from the certificate you received back to one of those trusted authorities. When the chain ends at a company-generated certificate that isn't on the CLI's list, the chain is broken as far as the CLI is concerned, and it refuses to proceed. That refusal is exactly what the AWS CLI's own troubleshooting documentation describes: the CLI doesn't trust your proxy's certificate because your company is acting as the certificate authority, which prevents the CLI from finding that root certificate in its local registry. The fix is to add that certificate to the CLI's list yourself.
- Get the certificate file from IT. Ask for the root CA certificate your company's proxy or security software uses, saved as a
.pemfile. If IT can export it from the antivirus console, that's usually the fastest route. - Confirm the file path is exact. On Windows this often looks like
C:\certs\company-ca.pem; on macOS or Linux, something like/etc/ssl/certs/company-ca.pem. - Set it in the AWS CLI: run
aws configure set ca_bundle /path/to/company-ca.pemfor a permanent setting, or add--ca-bundle /path/to/company-ca.pemto a single command to test it first. - Re-run the original command. If it succeeds now, you've confirmed the cause and the fix in one step.
⚠️ What this actually breaks
If you don't know whether your network runs traffic through a proxy or inspection tool, you can't self-diagnose this one from home. If your IT team won't produce the certificate file, you are not going to be able to fix this yourself from the CLI side — the proxy has to be excluded for AWS CLI traffic, or the certificate has to be handed over. That's a request to make of IT, not a setting you can invent.
Cause 2: your ca_bundle setting points at a file that isn't there
This is the version of the error that includes [Errno 2] No such file or directory right after "SSL validation failed." It's a different failure from Cause 1 even though it looks similar: the CLI isn't rejecting a certificate here, it's failing to find the certificate file at all. This usually happens because someone — possibly you, a few months ago while fixing Cause 1 — set a ca_bundle path, and then the file got moved, renamed, deleted, or the setting followed you onto a different computer where that path doesn't exist.
Run aws configure get ca_bundle to see what path is currently set. If nothing prints, the setting isn't in your config file — check whether an environment variable is overriding it instead by running echo $AWS_CA_BUNDLE on macOS or Linux, or echo %AWS_CA_BUNDLE% in a Windows Command Prompt. Whichever one shows a path, confirm the file genuinely exists at that exact location, then either fix the path or remove the setting entirely if you no longer need a custom certificate bundle.
🙋♂️ Jake's Reality Check
"I fixed this exact error six months ago on my old laptop. Why is it back on my new one?"
Because the fix lived on the old machine, not in your AWS account. A ca_bundle setting is stored locally in your CLI config file — it doesn't travel with your AWS profile or your credentials. Set up a new computer and you have to point it at the certificate file again, assuming Cause 1 still applies to your network.
Cause 3: the AWS CLI installation itself is incomplete
If you're on a home network with no company proxy anywhere in the picture and you're still getting this error, the CLI's own bundled trust store may be incomplete. This happens most often after an interrupted install, a partial upgrade where an old installer's files got left behind alongside a new install, or an install method that didn't fully replace an older one — several people hitting this exact error have resolved it simply by removing every existing copy of the CLI and reinstalling cleanly using the supported method for their operating system.
🙋♂️ Jake's Reality Check
"I only ever installed it once. How can it be 'incomplete'?"
The install itself might still have half-finished. Ethan's explanation: "Every install of the CLI carries its own bundle of trusted root certificates along with it, packaged with the program. If the install got interrupted — power blip, a closed terminal window, an update that ran over a partial install from before — that bundle can end up incomplete even though the aws command still runs fine for everything else. It looks finished. It isn't."
- Check for more than one installed copy. Run
aws --versionand note the version and path it reports, then check whether you also have a separate install from a different method (for example, both a system package manager install and a manual download). - Uninstall every copy you find, using the removal method that matches how each was originally installed — a package manager install needs to be removed with that same package manager.
- Reinstall using one supported method only, following the current installation instructions for your operating system, then close and reopen your terminal so the updated PATH takes effect.
- Run the failing command again to confirm the fix.
Cause 4: the AWS Region setting is wrong or missing
This one surprises people, but it's listed directly in the AWS CLI's own troubleshooting guide as a cause of this exact error. The AWS CLI needs a Region to know which service endpoint to connect to, either set explicitly with --region, through the AWS_DEFAULT_REGION environment variable, or in your profile's region setting.
🙋♂️ Jake's Reality Check
"What does a wrong region have to do with a certificate?"
Everything, once you see where region fits in. Ethan again: "Region isn't a filter you apply after the fact — it's part of the address the CLI dials before it ever asks for a certificate. No region set, or the wrong one set, and the CLI can end up trying to reach an endpoint that doesn't behave the way it expects. The certificate check just happens to be the step where that mismatch shows up first."
Run aws configure get region to check what's set for your active profile, and pass --region us-east-1 (or whichever Region your resources actually live in) directly on the command to rule this out quickly.
Cause 5: an outdated TLS stack on an older CLI or older OS
🕐 What changed between versions
- Before: AWS CLI version 1 relies on whatever TLS version the underlying Python install on your system negotiates, which on an old or unpatched system can fall short of TLS 1.2.
- Now: AWS CLI version 2 uses an internal Python build that's compiled to use a minimum of TLS 1.2 automatically whenever the service on the other end supports it, so you don't need to configure anything for this.
- What that means for you: if you're still running CLI version 1 on an older machine, this is one more reason to move to version 2 rather than chase a TLS setting manually.
TLS — the protocol behind the "S" in HTTPS — is the layer that actually negotiates and encrypts the connection before any certificate gets checked. AWS requires TLS 1.2 and recommends TLS 1.3 for communicating with its services. If your error text includes UNSAFE_LEGACY_RENEGOTIATION_DISABLED or an abrupt EOF occurred in violation of protocol, that's a TLS negotiation failure rather than a straightforward certificate trust problem.
🙋♂️ Jake's Reality Check
"I have no idea what version of the CLI I'm running. Is that even something I chose?"
Almost nobody chooses it on purpose. It's usually whatever was current when you or someone before you first ran the install command, and it never updates itself unless you tell it to.
- Check your version with
aws --version. Anything starting withaws-cli/1.is version 1;aws-cli/2.is version 2. - If you're on version 1, plan a move to version 2 using the current installation instructions for your operating system, since version 2 handles the TLS minimum for you.
- If you're already on version 2, confirm you're on a recent release rather than one installed a long time ago, since updated versions ship close to every business day and older ones can lag behind current service requirements.
Fixing "aws configure sso" SSL validation failed
The SSO wizard hits this error the same way any other command does — it's making an HTTPS request to your organization's access portal, and that request runs into the same trust problem as any other CLI call. The wrinkle is who tends to run into it: people setting up aws configure sso for the first time are frequently doing so on a managed corporate laptop, which makes Cause 1 — the intercepting proxy — the dominant explanation here specifically, more so than for a plain aws s3 ls.
The fix is the same one used for Cause 1: get the company's certificate file and set it with aws configure set ca_bundle /path/to/company-ca.pem before running the wizard again. Set it as a saved profile setting rather than trying to remember a command-line flag every time — you'll likely need it for every other AWS CLI command on that machine too, not just for SSO setup.
The --no-verify-ssl shortcut, and why it's the wrong move
Every list of fixes for this error eventually mentions --no-verify-ssl, and it's worth being straight about it: it works, in the sense that the command stops erroring. It also turns off the exact protection this error exists to enforce. With SSL verification off, the AWS CLI stops checking that it's really talking to AWS at all — traffic between your machine and AWS is no longer confirmed to be secure, and it becomes possible for someone positioned on your network to intercept it undetected.
🙋♂️ Jake's Reality Check
"Honestly, can't I just leave --no-verify-ssl in my backup script and move on with my life?"
You could, and it would run. But that script is uploading customer paperwork to a bucket every night. Ethan's answer to Jake was blunt: "You'd be turning off the one check that confirms it's actually going to your bucket and not somewhere else. Fix the certificate setting instead — it's the same three lines of effort, and then you're not gambling on it every night."
✅ Why this is the one to use
Fix the actual certificate trust problem instead — pointing the CLI at the right CA bundle takes about the same effort as adding --no-verify-ssl, and it leaves your connection genuinely verified rather than merely quiet about being unverified.
If you're only trying to confirm that a certificate-trust issue is the cause — not planning to leave it this way — running the command once with --no-verify-ssl to see whether it succeeds is a reasonable diagnostic step. It should never be the setting you leave in place, and it should never go into a script, a scheduled job, or anything that touches real credentials or real data on an ongoing basis.
Three ways to set your CA bundle, compared
The AWS CLI reads the certificate bundle location from three possible places, and it's worth knowing which one wins if more than one is set: a command-line flag overrides an environment variable, which overrides a saved profile setting.
🙋♂️ Jake's Reality Check
"Why does AWS give me three different ways to do the same thing?"
Because they solve different problems, not the same one. One's for a quick test, one's for a single tool, one's for everything at once. Use the table below to pick the right one instead of guessing.
| Method | Where it lives | Use it when |
|---|---|---|
--ca-bundle /path.pem |
Applies to a single command only | You're testing whether this is really the cause before committing to it |
AWS_CA_BUNDLE environment variable |
Current terminal session, or permanently if added to your shell startup file | You want it applied to every tool that reads this variable, not just the AWS CLI |
ca_bundle in the config file (set via aws configure set ca_bundle) |
Your AWS CLI profile, permanently | You want it to stick for this profile without editing your shell startup file |
If you manage more than one AWS CLI profile, remember that ca_bundle is a per-profile setting — set it again with --profile yourprofilename for each profile that needs it, or use the environment variable instead so it applies across all of them at once.
When none of the five causes fix it
If you've worked through all five causes and the error persists, stop guessing and gather evidence instead.
- Re-run the failing command with debug logging: append
--debug, and route the output to a file with2> debug.txtso it doesn't scroll past. - Search the file for "CAfile" to confirm exactly which certificate bundle the CLI loaded for that attempt — this tells you whether your setting was even applied.
- Hand the file to whoever manages your network or your AWS account, rather than continuing to guess — this is the same information AWS Support or an internal IT team would ask you for anyway.
At that point you're no longer troubleshooting alone; you're handing someone the evidence they need to look at their side of the connection, which is sometimes genuinely where the problem sits — a misconfigured internal firewall rule, a VPN client with its own certificate-inspection feature, or a proxy exception list that AWS's endpoints simply weren't added to.
🙋♂️ Jake's Reality Check
"I don't run IT. I just want my backup job to work again tonight."
Then send the debug log and go on with your day. That's a completely reasonable place to stop — you've done the diagnosis, and the rest is a conversation between the CLI and whoever controls your network's security tools, not something you're expected to solve solo.
Ethan's take, once Jake showed him the debug output that afternoon: "This one was never really about AWS. Your antivirus started doing something new, the CLI noticed, and it told you exactly that — in about the least readable way possible, but it told you." Jake got IT to add an exception for the CLI's traffic before that night's sync job ran, and moved on.
Don't confuse this with a permissions error
It's a common instinct to go straight to your IAM user or role when an AWS CLI command fails, because that's usually the culprit for AccessDenied or InvalidClientTokenId errors. SSL validation happens at an earlier stage entirely — the connection has to be trusted before your credentials are ever checked, so an SSL validation error tells you nothing about whether your permissions are correct. If you fix the certificate issue and then run into an actual permissions problem afterward, that's a separate topic with its own troubleshooting path — our guide to how IAM permissions work covers what those errors mean and how to read them.
Frequently asked questions
What does "SSL validation failed" actually mean?
It means the AWS CLI tried to verify the certificate presented by whatever it connected to, and couldn't confirm that certificate is trustworthy. It's a connection-trust failure, checked before your credentials or permissions ever come into play.
Is this error a sign my AWS credentials are wrong?
No. This error happens at the connection stage, before the CLI checks your access key or role. Fixing the certificate issue and then seeing a credentials-related error afterward would be a separate, unrelated problem.
How do I fix "SSL validation failed" for aws configure sso?
Set your CA bundle permanently with aws configure set ca_bundle /path/to/file.pem before running the SSO wizard, since people setting up SSO for the first time are usually on a managed device where a corporate proxy is the most likely cause.
How do I turn off SSL validation in the AWS CLI?
Add --no-verify-ssl to a command to disable certificate checking for that one call. This is not recommended for regular use, since it removes the CLI's ability to confirm you're actually talking to AWS securely.
Should I use --no-verify-ssl to fix this quickly?
Only as a one-time diagnostic to confirm the cause is certificate-related. Fixing the actual certificate trust setting takes about the same effort and leaves your connection genuinely verified instead of just quiet about being unverified.
What does "CERTIFICATE_VERIFY_FAILED self signed certificate in certificate chain" mean?
It means a certificate somewhere in the chain the CLI received was self-signed rather than signed by a certificate authority the CLI already trusts — the classic signature of a proxy or security tool that re-signs your traffic with its own certificate.
What does "unable to get local issuer certificate" mean?
The CLI received a certificate but couldn't trace it back to a trusted root in its own certificate store. This shows up with both intercepting proxies and incomplete AWS CLI installations, so check both causes.
Why do I get "[Errno 2] No such file or directory" with SSL validation failed?
Your ca_bundle setting points at a certificate file that doesn't exist at that exact path. Check the setting with aws configure get ca_bundle and confirm the file is actually there.
How do I find my company's CA certificate file?
Ask your IT or security team directly for the root certificate used by the network proxy or endpoint-security software, saved as a .pem file. There's no way to generate or guess this file yourself from the CLI side.
Can I use one certificate bundle for AWS CLI, Python, and other tools?
Setting the AWS_CA_BUNDLE environment variable is scoped to the AWS CLI and SDKs that read it; other tools have their own separate certificate settings and generally need to be pointed at the file independently.
Does reinstalling the AWS CLI fix SSL validation errors?
It can, specifically when the cause is an incomplete or conflicting installation. Uninstall every existing copy using the method that matches how each was installed, then reinstall cleanly using one supported method.
Why does this happen on my home network with no proxy?
Check for a broken or duplicate CLI installation first, then check your Region setting. Antivirus software that does traffic inspection can also be present on a home computer, not just a corporate one.
Is AWS CLI version 1 more prone to this error than version 2?
Version 2 uses an internal Python build set to a minimum of TLS 1.2 automatically, while version 1 depends on whatever TLS version your system's own Python install negotiates, which can lag on older systems.
Does the AWS Region I use affect SSL validation errors?
Yes. A missing or incorrect Region setting can send your request to an unexpected endpoint, which the AWS CLI's own troubleshooting documentation lists as a direct cause of this exact SSL error.
How do I permanently set the CA bundle so I don't retype it every time?
Run aws configure set ca_bundle /path/to/file.pem once, which saves it to your profile in the CLI's config file, or add the AWS_CA_BUNDLE environment variable to your shell's startup file for a setting that applies every session.
Is it safe to add my company's CA certificate to the AWS CLI?
Yes, in the sense that it's exactly what the CLI's own documentation describes as the correct fix — it lets the CLI trust a certificate your organization's IT team controls, rather than disabling certificate checking entirely.
Revision note. Written September 2026, covering AWS CLI version 2 and the still-common version 1 installs on older systems, across Windows, macOS, and Linux. This will need a fresh look if AWS changes how the CLI locates its default certificate store. If you're staring at this error at midnight because a backup job just failed, you're not missing something obvious — go through the causes in order, and you'll likely have it sorted before your coffee's cold.