0

Is it possible to digitally sign a document only with a x509 certificate (ie public key)?

We received a question from one customer saying that they wanted to sign a document using only a certificate. Is it possible?

I understand that the private key is needed in order to sign. The only case that I think this holds is that if the x509 certificate has embedded the private key, right?

In that case, even though it is password protected, if I hold that certificate I turn myself into the Single-Point-of-Failure if someone compromises my server and their password they can sign any document in their behalf. So, is embedding the private key less secure and it does not allow the public distribution of certificates?

Thanks!

Improve this question
  • Not totally sure of your question. I think you may be confused with how public/private keys work. Private keys are NEVER distributed under ANY circumstance. Also, you sign with a private key and the public key is used to validate the authenticity of the message. As only the private key holder can sign the message. – ISMSDEV Aug 22 '19 at 20:04
  • Our customer wants to sign with only a x509 certificate. What you say is how it is really supossed to work. You sign with your private key that's correct. My question is if it is possible to sign only with the public key in the x509 or if it is necessary to embed your private key in the certificate. In that case, I agree with you that you're implicitly distributing your private key and that you should't do that, right? – DraQ Aug 22 '19 at 20:36
  • NEVER distribute the private key. Otherwise you are destroying ANY purpose of using it. You can sign with x509 certificates, that’s common, but it’s the private key that is used to sign. It sounds like you are not totally sure on how it works, no rudeness mentioned at all, so I would seek to only implement something from the advice of an expert in this case. You don’t want to risk getting it wrong. All the best – ISMSDEV Aug 22 '19 at 20:48
  • If you sign with a private key it provides evidence of the source of the signed data. That is, only you have the private key, so the signed data came from you. If, on the other hand, you sign with the public key, you are stating absolutely nothing about the data. As a public key is, by definition, public knowledge, I could get hold of it and sign data in your name. The whole idea is completely pointless. – garethTheRed Aug 23 '19 at 5:25
  • There is a very simple argument as to why "only" having the certificate and nothing else is not enough for a signature: The certificate is presented to everybody to prove the identity of the one holding the certificate. If it were enough, then everybody could forge every signature. – MechMK1 Aug 23 '19 at 10:53
6

No, but.

Yes, technically you sign (or decrypt) with the privatekey, not with the certificate itself. And a publickey certificate never contains the privatekey.

But a lot of software, and thus documentation, and other description, blurs this distinction. We generally use a privatekey with a certificate (with the exception of SSH, where we attach limited metadata -- a host name or address, and sometimes other restrictions -- directly to a publickey), and the certificate part of this combination is more understandable and interesting to humans.

For example, the Microsoft Windows "Certificate Manager" displays things that are labelled "certificates" organized into things labelled "stores". You can have entries that are simply certificates (for someone else, usually a CA) or entries that are certificates with a privatekey attached (for yourself, or someone you are acting on behalf of). The fields of the certificate are displayed and at least some are meaningful to people: the subject name(s), the validity period, the issuer, sometimes the keyusage and/or extendedkeyusage. (Perhaps the transparency SCT(s) -- well, no, probably not. :-) The privatekey when present is not displayed (for security) and if it was it would be weird incomprehensible gibberish to 99.99% of users.

When you want to sign your email with Outlook, you go to a "Certificate Manager" window and select a "Certificate". Outlook includes this certificate in the outgoing email, and when the recipient displays that email their MUA shows it was "signed by the owner of certificate X" often elided to simply "signed by certificate X". Outlook did in fact use the privatekey to sign as well as putting the matching cert in the message, but the users see and identify and focus on the cert not the privatekey.

This is also reflected in the API; to actually do signing (or decryption) in Windows you get an object of type X509Certificate2 either from the store or by loading a PFX/PKCS12 file, which actually contains both the certificate and the privatekey.

MacOS keychain is similar, for certs with or without privatekeys (it also does passwords, which are different).

The same is true for TLS/SSL/HTTPS server and optionally client auth -- the privatekey is used internally, but the user(s) and admin(s) see and choose and think about the certificate. This definitely includes IE and Edge, and Chrome on Windows, and to my understanding Safari and Chrome on Mac. Firefox (and NSS) uses its own "cert database" instead of the system one, but it also describes and displays the entries as certificates whether or not they have privatekeys attached.

We often (IME) do the same for certificates themselves, which are also signed objects. For example, a few years ago people experienced trust issues with Google's (then) internal CA, "Google Internet Authority 2", because of the timing of some cross-CA bridging certs, IIRC between Equifax and Geotrust (or maybe the reverse). In answering some of those Qs I believe I talked about, say "this google cert X signed by this other cert Y". That is technically incorrect; to be exact I should have said "this google cert X signed by the abstract entity which is or at the relevant time was the verified owner of the cert Y using the privatekey which is part of the same keypair as the publickey that is in the cert and owned by the same owner as the owner of the cert and generated as a mathematically related unit". If I had done so, and repeated this 5 or 10 times for all the needed links in the cert chain, I would probably never have completed a single answer because it would have been too much work. To someone who knows how public key crypto works, "cert X signed by cert Y" is easily understood even though technically wrong, and to someone who doesn't know, it doesn't make any difference.

BTW, Java goes the opposite way. It has "keystore" files (or sometimes nonfile storage like a PKCS11 token) that can contain (either) lone certs for others, usually a CA, or privatekey-plus-cert entries for yourself. People get these confused just as easily as they do the Windows/Mac/FF approach; I personally have answered at least a dozen Qs here and related Stacks from people who imported a lone cert to their Java keystore when they needed a privatekey plus cert.

GPG traditionally has a "key ring" which contains publickeys with added metadata and (canonically) signature(s) that are in effect certificates, though not called that, and (matching but separate) "secret" keys which are really privatekeys. (This follows PGP, which was designed back in the 1990s before the privatekey-vs-secretkey terminology was settled.) OTOH its newer GUI Kleopatra calls them (together) certificates. Pick your poison.

Improve this answer
  • In other words: OP is technically correct, but probably misunderstanding their customer's request, possibly because the customer doesn't precisely know what they're asking. – Ben Aug 23 '19 at 13:53
  • @Ben I think that he is confused about how it works. Even though I explained this issue I was not able to match this to the theory. That's why I was asking for second opinions in case I was missing something. – DraQ Aug 23 '19 at 14:38
  • @dave_thompson_085 why whould someone share or use a certificate with a private key embedded? Apart from using it inside a keyring application or like you said in another software like Outlook where you can sign and then present the certificate to the recipient of the email? – DraQ Aug 23 '19 at 14:41
  • 1
    @DraQ: it's never in the cert, but as I said may be attached (for example, in a PKCS12 aka PFX file). Someone would share a key and cert to allow someone else to sign and/or decrypt 'on their behalf' (like a supervisor giving this to a subordinate to cover during a vacation or absence, or a webserver allowing a loadbalancer, WAF, CDN, or other 'front end' to handle traffic addressed to it) or 'with equal ability' (like members of a collective or partners in a business, or a normal and backup datacenter). ... – dave_thompson_085 Aug 24 '19 at 11:27
  • ... The same mechanism is also used to transfer key&cert, e.g. a business gives you a key&cert (in your name) to use to authenticate yourself to their server or workflow, and after that they don't use that key&cert. This is not best practice, which is for you to generate the key and them to authorize or provide only the cert, but with some users the best practice takes days of handholding and it's cheaper to just do the poor practice. Yes, if you have someone's privatekey you can sign or decrypt 'as' them, and can misuse this power. If you don't want the responsibility, don't accept it. – dave_thompson_085 Aug 24 '19 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.