1

Is it true that you can only decrypt data that was encrypted by a certificate using the same exact thumbprint? 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.)

Wouldn't I still be able to decrypt the same data using both certs? 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. Am I missing something? If this were true, wouldn't it wreck havoc anytime an encryption certificate were to expire? Someone would renew the encryption certificate and find out that they couldn't decrypt any of the data that was encrypted by the old certificate.

Edit The scenario is that a self-signed certificate, which includes a private key, is used to encrypt data using the public key portion, and is also used to decrypt data using the private key. As others have pointed out, folks here want to be very specific to say it's not the certificate that encrypts data. That's fine, we don't really specify it to that level in my team as everyone knows we're implying the public key encrypts and private key from the certificate decrypts the data, but I now remember how specific folks get on forums. Anyhow, we have a certificate that's encrypting data and also decrypting data. The self-signed cert seems like a very bad idea. My suggestion was to avoid using a self-signed certificate altogether as I could create a certificate that has the same SubjectName as the target certificate. My thought was, can the private key from a self-signed certificate with the same SubjectName be used to decrypt the data? 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).

5
  • If I understood the question correctly it depends on forward secrecy. If you have it you can only decrypt the data within that specific period only with that specific correspoding certificate. Commented Aug 22, 2022 at 16:37
  • Certificates are not used to decrypt data. Certificates contain a public key. The public key in the cert can be used to encrypt data. Then, the private key associated with the public key in the cert can be used to decrypt this data. But, the private key is not included in the cert (because the cert if public). If a message was encrypted using the public key in an expired cert, the message can still be decrypted if the owner of the cert still has the corresponding private key.
    – mti2935
    Commented Aug 22, 2022 at 17:28
  • I get what you're saying but to me it reads a lot like a car doesn't actually drive. It's the engine that ultimately moves the wheels. Also, the original question I think wasn't addressed. The person I spoke to said that you can prevent decryption of the data that was encrypted using the public key from the older certificate whenever you try to decrypt it using the private key from the renewed certificate. Someone here said private keys are not part of the certificate. I get what you're saying, I see a lot of private key files standalone, but you can still have a private key with the cert
    – q933a
    Commented Aug 23, 2022 at 0:15
  • If 'renewal' generates a new keypair and cert, data encrypted using the new cert can't be decrypted by the old privatekey and data encrypted using the old cert can't be decrypted by the new privatekey. But data encrypted using the old cert can still be decrypted by the old privatekey regardless of the cert expiring, unless you have some process that deletes the expired cert and its key. And there is no standard for 'renewal'; some people create a new cert for the old keypair, in which case data encrypted with either cert can be decrypted by the (one and the same) privatekey. Commented Aug 23, 2022 at 3:07
  • 2
    ... In no case does the thumbprint have anything to do with the encryption or decryption, except that some software, particularly if designed for the OS-provided store/API on Windows, likes to use thumbprint to identify a cert and key, and if your software does that and you don't have the correct thumbprint available it may take a microsecond or two longer to find the correct cert/key. Commented Aug 23, 2022 at 3:10

3 Answers 3

5

Semantics do matter here. Even though you don't "specify it to that level" in your team, you are on Security SE, and I would advise you to be very careful when handling the public key/certificate versus the private key. This implies using proper terminology when working with them. (Imagine someone sending the "certificate" including the private key to an external 3rd party!)

Public key, private key, certificate, and fingerprint

Simplified, the public and private keys are 2 pieces of data that are bound by cryptographic properties: what one could encrypt, the other could decrypt. But while the former will be shared publicly, the latter has to be kept secured.

The certificate is here, well, to certify a public key. Basically, the certificate is a public key with additional information to ensure its validity: who owns it, what it can do, the validity time frame, etc. and of course the whole thing is protected with a fingerprint. That fingerprint ensures that the previous information were not modified by an illegitimate third party.

If it expires, can it still be used?

The certificate is here to provide trust and part of the technical mechanism is the fingerprint. However, nothing prevents you to use the embedded public key, even if the certificate is invalid. This includes expired certificate. This include if someone changed the CN and let the fingerprint wrong.

So you can still use the public key to verify signatures generated with the private key. Alternatively, you can still use the private key to decrypt data encrypted with the public key. They did not suddenly change.

What about certificate renewal?

It depends what you mean by certificate renewal. From what I am guessing with you using self-signed certificate, you may be generating a new key pair every time. You have to check that.

If you renew the key pair (private & public keys), then yes, you will need the old key pair.

If you did not change the key pair and used it to renew your certificate, then the new one will work just as fine as the old one1, simply because what's being fed to the cryptographic functions did not change2. When you renew your id, you do not change, you just get some authority to stamp a new document stating you are indeed who you pretend to be for the next x years.


1: the old one will probably be refused by the clients due to its expired status, but one could technically bypass it and still use the embedded public key.

2: The fingerprint on the certificate will be different, indeed, simply because the certificate is different (e.g, the validity time frame), but that's just something someone can use to verify the certificate (trust), it does not participate in the decryption/encryption process.

3

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.

5
  • My issue isn't so much with being precise with the language. It's with the way you guys present it. If you guy's intention is to teach then I sure don't want teachers like you that sound like, on text, to enjoy talking to people with aggressive and even passive aggressive language. My org actually does pretty well, and people here don't nit pick and if they do need some clarification on terms, they don't go about it in a very condescening and patronizing way. I used to moderate on a very popular technical forum and most folks there were way more respectful in tone
    – q933a
    Commented Aug 24, 2022 at 0:08
  • Which is true, but that's very elementary and unsurprising. However: All that just sounds unnecessary for me. Why even talk like I had defecated on your grandfather's grave? Elementary and unsuprising? When guys like you who hide behind a screen and appear like you're trying to get a rise out of condescending people, then it leads me to believe you might live a sad life and this is the only enjoyment done in a negative way you can get. If you don't live a sad life, then don't make it look like you do by how you come across.
    – q933a
    Commented Aug 24, 2022 at 0:11
  • 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 that isn't necessarily true. It's just your opinion. It's not a rare thing that if someone has a certificate, they would think there is a private key associated with the certificate. And I can get a private key from creating a self-signed certificates all day.
    – q933a
    Commented Aug 24, 2022 at 0:11
  • Go in to IIS manager and create a self-signed certificate and notice you automatically get the private key associated to the cert. I think you guys want to control the narrative as if you're justified to talk down to someone and are really desperate to do so and adding a lot of unnecessary fluff and angst during the discussion.
    – q933a
    Commented Aug 24, 2022 at 0:16
  • I frankly know a lot of people that would fine this discussion disgusting and is typical of people to think if they know something well, then they can talk down to people. I'm cut from a different breed, where people appreciate me for not yelling at them (in their own words) for explaining a pretty intricate process to a team of senior devs. I don't find much of this discourse towards me as healthy and more like you guys are blowing off some steam. I'd say grow up and find something more productive to use your energy on
    – q933a
    Commented Aug 24, 2022 at 0:17
2

A certificate doesn't encrypt data, and definitely doesn't decrypt it.

  1. A certificate contains a public key, and that public key can be used to encrypt data.
  2. That public key was created using a private key, and together they form a key pair.
  3. The private key can be used to decrypt a message that was encrypted using the public key.
  4. The private key is not a part of the certificate. If it was, anyone who has access to the certificate (which is typically public) could decrypt the messages.
  5. When updating a certificate, you typically generate a new key pair.
  6. This means if I use the public key in a certificate to encrypt a message, decrypting it would require the private key that created it, which is not the same as the private key used to create the updated certificate.
12
  • "When updating a certificate, you typically generate a new key pair." - It is not uncommon to keep the same key pair in order to make things like public key pinning possible without always distributing new pinning information with each new certificate update. Commented Aug 22, 2022 at 19:21
  • 1
    Isn't it inaccurate to say certificates don't have private keys? - No. In your browser, if you view the certificate for page that you are at now, you will see that the certificate contains a public key, but not a private key. On some servers, the certificate and the private key can be stored together in the same file, but that is not the same as saying that the certificate contains the private key.
    – mti2935
    Commented Aug 23, 2022 at 11:45
  • 1
    The reason that you got an explanation about what components of a certificate are used to encrypt or decrypt as if the person responding is signaling that he doesn't think I understand this is because you were asking about using a certificate to decrypt data. This is just fundamentally incorrect. Even though you seem to understand the relations between these concepts from the dialogue following the question, posing the question in this way signaled that there may be a misunderstanding in your knowledge.
    – mti2935
    Commented Aug 23, 2022 at 12:04
  • 1
    To answer your underlying question - In the end, the certificate doesn't matter, it's the keys that matter. If a message was encrypted using a public key, and the private key associated with that public key is still available, then the message can be decrypted. Whether or not a certificate that contains this public key is expired, renewed, renewed with the same key, renewed with a different key, etc., is irrelevant.
    – mti2935
    Commented Aug 23, 2022 at 12:06
  • 1
    @UrielZylbermann you mean a later expiration initially? Simply put, for the same reason JWTs have a short expiration even though they can be refreshed: it limits the damage if the JWT (or, in the case of certs, the associated private key) gets compromised. Certs do have a revocation mechanism (a couple, actually) unlike JWTs, but not everything checks it and it's not perfectly reliable (e.g. lots of software will default to accepting a cert if they fail to pull revocation info, assuming they even try). If you're pretty sure the key hasn't been compromised though, might as well keep using it.
    – CBHacking
    Commented Aug 25, 2022 at 0:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .