| View previous topic :: View next topic |
| Author |
Message |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
 Posted: Sat Oct 07, 2017 10:50 pm Post subject: Create SSL certificate without providing private key |
 |
|
Is it possible to create an SSL certificate without using its related private key in the process?
Sure, usually you have to generate the key pair, then create CSR using this key pair, and then sign it with CA to complete the process.
Now, here's the scenario:
1) I control CA
2) Existing certificate is public/available to me
3) Private key is _NOT_ available to me.
Can I issue a new certificate using only the data pieces available to me? (I want to reuse existing key and change metadata, like name or validity)
Note: this scenario is valid in terms of security - it does not imply any loopholes or gaps in the system. You still have to know the private key to use your certificate. And signing CSR with its related key is neither necessary nor even useful for verifying identity anyway. Signing the CSR is good when it serves as a cheap validity test (AKA does the user have the related private key?), but CA could just consider it user's responsibility and proceed with verification anyway.
Still, there may be some restrictions within the protocol (e.g. cert must be signed by both, CA and user's private keys) or within the implementation (executables refusing to cooperate without private key in sight).
So, any ideas how can I update a certificate? If available tools do not allow it, what is the actual roadblock? |
|
| Back to top |
|
 |
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia
|
| Posted: Sun Oct 08, 2017 4:13 pm Post subject: |
|
|
In a word, no, or more precisely, not with standard tools. Certificate requests are "self signed" not only to prove to the CA that creator of the certificate request has the ability to wield the private key, but also to vouch for the other information in the certificate request. Since you don't have the ability to wield the private key, a standard CA will not grant you a cert because you can't vouch for any of the information you want included in the cert. I think your comment on there being no security issues boils down to, "My heart is pure." Say I want a certificate that's purely used for TLS sessions and the extended key usage extensions in my certificate request so indicate. Do you think I'd be comfortable knowing that the CA had policies in place such that at a later date they might come back and add different certificate extensions, say to add Code Signing to the key usage? No I would not.
Now, that said, many crypto libraries have the ability to generate and sign an ASN.1 certificate object, libcrypto among them. You'll never, ever find what you're asking for as an off-the-shelf capability, though.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.
Last edited by John R. Graham on Sun Oct 08, 2017 4:48 pm; edited 1 time in total |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Sun Oct 08, 2017 4:48 pm Post subject: |
|
|
| As I understand it, the actual wielder of the private key can create a new certificate with the existing public/private key (but different metadata) and submit a certificate signing request to the CA for that new certificate. This allows the key to remain the same, but as JRG says, still requires that it be done by the holder of the private key. |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia
|
| Posted: Sun Oct 08, 2017 5:00 pm Post subject: |
|
|
This is most likely what you meant, but pedantic corrections applied anyway: | Hu wrote: | | As I understand it, the actual wielder of the private key can create a new certificate request containing[deleted "with"] the existing public [deleted "/private"] key (but different metadata) and submit a certificate signing request to the CA for that new certificate. This allows the key to remain the same, but as JRG says, still requires that it be done by the holder of the private key. |
(I wish we had strikethrough available as a formatting option.)
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Sun Oct 08, 2017 5:27 pm Post subject: |
|
|
Not with standard tools. So... Does the signature on CSR affect the final certificate, or can I just patch the sanity checks out of my way, and rely on "external" validation (which any CA has to do anyway)?
| Quote: | | Technically, you could write code to create the cert if you control the CA, but it's such a bad idea from a general security policy perspective that I don't think you should even try, even if it's just for you |
A fair warning. Yes, reusing a single key for multiple certificates generally is a bad idea, keys could leak or disclose user's identity, but in this particular use case I'm not really concerned with disclosing identity due to a shared key, and in case of a leak, you can think of those certs as being half-way to the wildcard side. Leaking a key shared by a dozen of certs doesn't make it worse than leaking a key to a single cert used by a dozen of systems.
What risk do I miss here? It's never too late to learn something new.
The easiest way would involve storing or generating private keys in a location available to CA. You trust your CA, don't you? I certainly do, but I still don't like this idea.
| Quote: | | It's probably better for you to learn to work within the normal constraints. |
Yup. It certainly would be better. Too bad, there are also constrains placed in people's brains.
If it isn't ridiculously low-maintenance, it's not gonna be used.
edit:
| Quote: | | , the actual wielder of the private key can create a new certificate with the existing public/private key |
Yup. But this requires the wielder of the private key to actually do something, and this is what I want to remove from their hands. Distributing only the public data is much easier to do, and the wielder of the private key can still decide whether or not to use this updated certificate. And nobody but wielder of that private key is able to use it anyway. |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia
|
| Posted: Sun Oct 08, 2017 5:42 pm Post subject: |
|
|
| szatox wrote: | | Not with standard tools. So... Does the signature on CSR affect the final certificate, or can I just patch the sanity checks out of my way, and rely on "external" validation (which any CA has to do anyway)? |
No. The CSR signature doesn't live beyond its validation by the CA. However, see my edited first response.
Also, it's not reusing the key that causes the security risk. Many CA's support certificate renewal, but note that the only things that change during renewal are the validity dates.
An important security best practice is that private keys are private: they should never be shared. Or, more pedantically, there are very few USE cases where private key sharing is actually required and, if it's not required, it shouldn't be done. It basically guarantees scrutiny (and derision) during a design audit.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Sun Oct 08, 2017 6:18 pm Post subject: |
|
|
Thank you, that's a pretty good insight now.
| Quote: | | your comment on there being no security issues boils down to, "My heart is pure." |
It better be pure. I'm a CA, remember?  I can even issue a new certificate with MY key in your name and declare it's valid. This is the biggest problem with a CA. I mean, anything that is not enforced by the protocol itself is a matter of trust. I agree it sucks, if you can find a way that eliminates this flaw and is still usable, I will happily become an early adopter.
Too bad, verifying every peer by myself hardly qualifies as "usable". It fails as soon as we scale out to anything bigger than a "tribe".
| Quote: | | Say I want a certificate that's purely used for TLS sessions and the extended key usage extensions in my certificate request so indicate. Do you think I'd be comfortable knowing that the CA had policies in place such that at a later date they might come back and add different certificate extensions, say to add Code Signing to the key usage? |
Good point. Unfortunately: see #1. There is no higher authority to ensure your CA of choice follows it's declared policy anyway.
However, I've been thinking about this one too. It seems reasonable to limit CA to a particular task or domain. Would that make you more comfortable? |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia
|
| Posted: Sun Oct 08, 2017 7:48 pm Post subject: |
|
|
| szatox wrote: | | There is no higher authority to ensure your CA of choice follows it's declared policy anyway. |
Yes there is: it's called the root CA. It's why an X.509 PKI is sometimes called a "chain of trust" and also why you might want to consider not operating a root CA (and also consider creating and honoring CRLs throughout your PKI). If I'm your customer, it gives me a point of appeal. I can go to the root CA operator and say, "Szatox is a bad actor. Here's my proof. Please revoke his CA cert." The users of your issued leaf certificates can tell whether your CA cert has been revoked. Now that's not to say that all top level trust providers have a lily white reputation. There are a few examples of pretty spectacular fails out there, but the system does add value. Of course, PKIs can add value in small embedded environments where the root (and entire PKI) is private, but I thought you'd like to see the concepts.
| szatox wrote: | | It seems reasonable to limit CA to a particular task or domain. Would that make you more comfortable? |
Yes it would.  That's actually another security best practice: a cryptographic key should be used in the minimum scope that the architecture allows. It minimizes the portion of your system that will be compromised if the key is compromised.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Sun Oct 08, 2017 10:57 pm Post subject: |
|
|
Yes, running an intermediate CA is surely much easier and cheaper path than becoming a widely trusted root CA. I will certainly consider it once/if I get big enough to afford it. In the mean time, locally trusted root CA will be fine for a proof of concept.
Right now I'm doing some basic research, testing limits, estimating difficulty level of various components... Nothing is set in stone yet, I can still redesign the original idea or even trash the whole thing and pick something else if it turns out too hard or not useful enough.
CRLs are of course another thing that will require some attention (*cough* integration...), but let's take one step at a time. At least this part is going to be "easy", since providing CRL is a standard feature of any CA. I suppose I'll find enough papers regarding this topic to get me started.
Thank you for your help, there were a few good points. Some even not covered on the web until now, so in the worst case, at least we leave some trail for other curious beings  |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
