1

I understand the risks of a self-signed certificate used to enable HTTPS on a server.

My question, however, is about HTTPS client certificates.

Imagine the following scenario. I want to be able to authenticate a bunch of tech-savvy users on a public website without requiring them to pass through OpenID or requiring a password.

I start by generating a self-signed root certificate that I store on the server. In the context of this question, let's assume this root certificate will be protected against hackers.

From this root certificate, I generate several client certificates, one for each user, and transmit the .p12 file to those users in a safe way. They add those certificates to their browsers, and can now be authenticated.

Is there any security issue that the root certificate was self-signed? How would this compare to, for instance, using Let's Encrypt derived certificate as a root certificate (which is possible to do, since I do have the private key on the server as well)?

It seems to me that in terms of certificate revocation, it is as simple as regenerating the certificate, would it be the root certificate if this was the problem, or a client certificate. Is there anything else I'm missing?

Improve this question
2
  • Client certificates are a pain to set up and probably less convenient even for tech savvy users.
    – Elias
    Dec 2, 2017 at 10:21
  • I agree. Download the .p12, import it to the browser, enter the password. Go to the website which requires the certificate. Pick the one you just downloaded and confirm. This is indeed much more complicated compared to let the browser auto-complete your user name and password and submit the login form. This is why, in practice, client certificates are mostly used in corporate environments, where they are deployed and installed automatically on staff machines.
    – Arseni Mourzenko
    Dec 2, 2017 at 10:28

2 Answers 2

Reset to default
2

What you are doing there is basically becoming your own certificate authority - which is fine, as long as you accept the risks associated and/or mitigate them.

In this scenario you can safely base your servers trust in your own certificate to issue client certificates as long as you are fine with your own CAs method of establishing trust in the users identity.

I’m not too sure let’s encrypt will give you a certificate that has the CA attribute set (i.e. can act as a certificate authority). While you might have the key for the certificate, that certificate does not allow signing certificates itself.

Certificate revocation should be handled internally (your server should know which certificates should no longer be accepted) at least; you do not need to provide CRLs if you only use the CA internally.

You can also establish a 1:1 connection between user and certificate, replacing the revoked certificate with a new one should be fine then.

Improve this answer
0

I think one should return to the basics to see the issue or non-issue of this. Certificates are a way to use a trusted third party, called a Certificate Authority, in order to know that a public key is indeed the public key of the entity it claims to be. If you have a safe and sure way to give a private key to someone (the .p12), of course you know the public key that goes with it, you have no doubts about its origin. You don't need any "certificate". You don't need any trusted third party to make sure that the public key you generated yourself, goes with the private key you gave safely (by your assumption) to the client in question. You are in fact re-inventing a kind of ssh but with keys embedded in certificates of which the signatures don't matter here.

A self-signed certificate is nothing else but a public key in a fancy format. Anyone generating a public key (and the private key that goes with it), can also generate the self-signed certificate that goes with it. The trusted third party is here the provider of the public key. In as much as you can trust him, you can trust the public key directly, and you don't need a certificate ; and in as much as you can't trust the origin of the public key directly (which was the reason to use certificates in the first place), well then you can't trust the signer of the certificate either because its the same.

As in your application, which is nothing else but a typical ssh-type application, the software needs certificates, you embed the keys in a certificate, but these signatures don't have any security meaning here.

Improve this answer
6
  • 1
    A certificate is not a public key in fancy format. The certificate states the applications that are allowed, for example. Thus, you can trust a self-signed cert for encryption, but not for signing - you can not do that with just a public key.
    – Tobi Nary
    Dec 2, 2017 at 16:39
  • Yes. The point was of course that it was implicitly assumed that this information came with the public key, which would be useless without it. A public key without extra information like who's the owner, what it should be used for etc... is useless by itself, so I tacitly supposed that the information came with it. The difference with a certificate is that a certificate contains these information fields and is signed by a trusted party that links these together.
    – entrop-x
    Dec 2, 2017 at 17:07
  • (too late to edit): in a self-signed certificate, the signature doesn't add any trust value, so it is equivalent to just the public key and the information that goes with it. Anyone who can generate a public key, can add the information he wants, to it, and self-sign it. So whether he signs it or not, doesn't matter.
    – entrop-x
    Dec 2, 2017 at 17:18
  • In this case, the certificate acts as a container for exactly these information, trusted by OP and handed to the clients. Thus, there is a significant difference to just a public key (or one with additional information). If OP would have done this differently, I would have said „become your own CA; that is what certificates are for“. You too, hopefully:)
    – Tobi Nary
    Dec 2, 2017 at 17:21
  • I've noticed you refer to plain public-key authentication as "ssh". Although it makes sense for majority of readers, I'd like to point out ssh supports full blown certificate authentication for quite a while.
    – kubanczyk
    Dec 2, 2017 at 17:56

You must log in to answer this question.

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