AWS EC2 SSH worked yesterday. Today, Permission denied (publickey) - amazon-web-services

Question

The difference between this question and all the others comes down to this: yesterday, I could connect via SSH just fine using this command:
ssh -i "~/.ssh/[.cer file]" ubuntu#[Public IPv4 DNS]
(A .cer file is created instead of .pem since I use Chrome.) Then I shut down the instance and deleted the volume (after creating a snapshot) then I went home.
Today, I did the following:
Created a new volume from the snapshot, and attached it to the instance
Created an Elastic IP address and assigned it to the instance
Started the instance
Tried connecting via SSH using the new Public IPv4 DNS. I got a Permission denied (publickey) error.
Thinking it may have something to do with the Elastic IP, I dissociated the Elastic IP and rebooted the instance to get a new temporary IP.
I tried using ssh using the same command (with the new Public DNS) and am still getting the Permission denied (publickey) error.
Here is the log I get when adding -v to the command:
OpenSSH_8.6p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/WonderWolff/.ssh/config
debug1: /Users/WonderWolff/.ssh/config line 14: Applying options for *.compute.amazonaws.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to ec2-13-57-238-91.us-west-1.compute.amazonaws.com port 22.
debug1: Connection established.
debug1: identity file /Users/WonderWolff/.ssh/rei_development.cer type -1
debug1: identity file /Users/WonderWolff/.ssh/rei_development.cer-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
debug1: compat_banner: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10 pat OpenSSH_6.6.1* compat 0x04000002
debug1: Authenticating to ec2-13-57-238-91.us-west-1.compute.amazonaws.com:22 as 'ubuntu'
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256#libssh.org
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: aes128-ctr MAC: umac-128-etm#openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-128-etm#openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:LnRbxnhhpoLZeIUFXFzOybmc+cPvutkYqZCmUmq+zVw
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
Warning: Permanently added 'ec2-13-57-238-91.us-west-1.compute.amazonaws.com' (ED25519) to the list of known hosts.
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /Users/WonderWolff/.ssh/rei_development.cer explicit
debug1: SSH2_MSG_SERVICE_ACCEPT received
Unauthorized use is strictly prohibited. All access and activity
is subject to logging and monitoring.
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/WonderWolff/.ssh/rei_development.cer
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
ubuntu#ec2-13-57-238-91.us-west-1.compute.amazonaws.com: Permission denied (publickey).
If it worked yesterday after multiple stops and reboots (I stopped and rebooted multiple times yesterday), what could possibly be the issue? Was attaching a new volume created from a snapshot the issue?
UPDATE: I created a new instance using the same keys. Connecting to that instance works, no problem. But I would still like to understand why either the removal and re-association of a volume, OR the assigning an Elastic IP address, OR a different reason I don't yet know causes me to get a Permission Denied error with the first instance.