Is it true that you can only decrypt data that was encrypted by a certificate using the same exact thumbprint?
This question doesn't really make sense, which is I think the source of the confusion. You don't decrypt data with a certificate. You don't even encrypt data with one, but at least there, there's an obvious missing step: you can encrypt data with the public key from a certificate (sometimes, if the public key is a kind that supports encryption, which in practice mostly means RSA these days). There's no such obvious step for (asymmetric) decryption, because a certificate does not include a private key (not even a self-signed certificate!). The closest you can get is:
Is it true that you can only decrypt data using the private key that is the counterpart of the public key used for encryption?
Which is true, but that's very elementary and unsurprising. However:
- having a certificate does not imply having a private key
- having a private key does not imply having a certificate
- multiple certificates can use the same public key
The certificate per se has nothing to do with either encryption or decryption, aside from being a place you can find the public key and the identity of the private key's holder.
With that said, hopefully the rest of this follows clearly to you:
My thought was that you can decrypt the data using an updated version of the same certificate with just an expiration date that's further into the future. This certificate will have a different thumbprint, but everything else remains the same (e.g., SubjectName, SAN, etc.)
Those things (expiration date, subject name, etc.) are part of the certificate but not the private key, and therefore irrelevant to decryption (and encryption, but especially decryption).
Someone told me that I can only decrypt the data by the older certificate. Trying to decrypt the data (that was encrypted with the older certificate) using the new certificate wouldn't work.
This person is even more confused than you are, and you should probably not trust anything they have to say about cryptography. If you still have the private key corresponding to the public key that was used to encrypt the data, you can decrypt the data. If you don't, you can't. It does not matter whether the public key is now, ever was, or will ever be in zero, one, or many certificates, whether the certificate[s] expired or not, whether a certificate has been re-issued or otherwise updated, etc.
The scenario is that a self-signed certificate, which includes a private key
No it doesn't. You might have a single file that contains both a certificate and a private key, but they aren't the same thing. Copying the Gettysburg Address and a picture of a dog into the same document does not mean that the Gettysburg Address contains a picture of a dog, even if you save the file as "Gettysburg Address.docx" with the picture of the dog still in there. Like the Gettysburg Address, a certificate is a specific and specifically-organized collection of data; it can be stored in a file, but it is wrong to say that the file is the certificate, only that the file might contain the certificate (and other things, like potentially the private key corresponding to the public key in the certificate).
This might sound pedantic to you, but this kind of precise thinking is essential in security (or really, in any kind of technical discussion, but the failure is perhaps most devastating when it is missing from security). You can say "everyone knows we're implying the public key encrypts and private key from the certificate decrypts the data" but the degree of incorrect assumptions about the entire cryptosystem implied by that statement make me concerned about the security of your software in general. As for "I now remember how specific folks get on forums", I wouldn't accept a technical specification that wasn't clear whether the code was supposed to accept/supply a string, a BigNumber object, a ByteArray, an X509Certificate object, a KeyPair object, a PublicKey object, an opaque handle, or some other way of representing a cert and/or public key - all of those could refer to the same key, some in several different ways - and neither should you. In technical discussions, rigor is important, and sloppy language leads to misunderstandings and errors
The self-signed cert seems like a very bad idea.
Not really relevant to the question, but: why? The danger of self-signed certs is that if you get one from somebody else, you have to take them at their word that the key it contains belongs to who the cert (or the person handing it to you) says it does. That's it. I expect that concern is totally irrelevant to this scenario.
My thought was, can the private key from a self-signed certificate with the same SubjectName be used to decrypt the data?
If it's the private key corresponding to the public key - not the certificate - used for encryption, yes. If not, no. The SubjectName - like all the other parts of the certificate that aren't its public key - is completely irrelevant.
The person that I spoke to explained that once the self-signed certificate is renewed, then it cannot decrypt data that was encrypted using the older self-signed certificate (that has the same SubjectName).
Again, this person is deeply confused about the very nature of certificates and asymmetric cryptography. "Renewing" a certificate is a matter of bookkeeping, nothing more or less; you are simply updating a record somewhere of what the current certificate is. The old certificate doesn't go away (unless you delete all available copies of it). The old private key definitely doesn't go away, whether or not the new certificate uses the same public key as the old one, unless you delete that too. Obviously if you generate a new key pair, and then a new certificate with that new keypair, and then delete the old keypair (and optionally the old certificate too), then of course you can't decrypt data encrypted with the old public key... but that has nothing to do with the certificate (either one), and everything to do with having deleted specifically the old private key. If you use the existing keypair to generate a completely new certificate indicating that it is valid from 2378 until 40000 BCE and containing "Bob's left-most eyebrow hair" as the subject CN, and replace the old cert with that one... well, you might confuse some libraries that attempt to validate the certificate, or that attempt to find it by the old CN, but the private key will still work for decrypting data encrypted using the public key from the old certificate.