SSL Self-Signed Certificate

2
votes

First of all I know that I have a lot of misconceptions about fundamentals of SSL.

But before, I want to give information about my goal; There is a Windows forms application written in C# and there is a asp.net WebApi that is integrated to this Windows app. Clients those are connecting to API are written in several programming languages. We need to add SSL somehow. this is not a public application and clients will build their client apps with the client certificate we will give them.

And here are lines of my knowledge about SSL those can be wrong or right;

-Self-Signed Certificates are more secure than bought ones. Becuase some known certificates can made unsecure by apps like Charles.

-For this scenario that i mentioned above as goal, there must be three certificates separately;

  • root cert,
  • a server side cert related to root cert,
  • a client side cert related to server cert.

-Every client can have same client side certificate.

-Visiual Studio Command Prompt is enough to create these certificates.

Also I need a source of documents to complete all these steps.

2
c#ssliisasp.net-web-apihttps
"Because some known certificates can made unsecure by apps like Charles." -> huh? What leads you to believe that Charles wouldn't be able to self-sign new certificates even if you use a self-signed certificate? The whole reason Charles and Fiddler can do it is because you accept their root certificate. - Llama
"Self-Signed Certificates are more secure than bought ones." - Source, please. - Fildor
"a server side cert related to root cert" - what does "related to" mean? And what are you going to use the certificates for? Do you want to use Client Authentication? - Fildor
@Fildor and john, there is no source, It's my preconception; If the machine that wants to track requests and responses hasn't got the any certificate, it can't. But known certificates can be at any machine by Charles or others. - Gogo-the-Cat
@Gogo Charles, etc. sign and install their own certificates (on your machine) for the pages you access through them. They have no access to the original certificates any more than you do. They simply man-in-the-middle it: they rebrand it with their own SSL certificate, effectively. - Llama

2 Answers

3
votes

Self-Signed Certificates are more secure than bought ones.

nope ... self signed certs are just certs that a client can not verify on its own because there is no trusted third party saying: "this cert is ok"

you have to have your own way of securely delivering the cert to the client, possibly by having an admin manually installing them or bundling them with your app...

if you have no control over some of the clients, things tend to get ugly with self signed certs...

For this scenario, there must be three certificates separately;

root cert,
a server side cert related to root cert,
a client side cert related to server cert.

as far as i understood, you want x509 certs for SSL/TLS to authenticate the server and to avoid MITM attacks, not for client recognition by the server

in this kind of scenario you need only one certificate, or maybe two if you want to base your own PKI on this later ...

the case with one cert:

create a keypair and selfsign a x509 cert with that ... private key stays with your server, the public key will be included in the cert, which is shipped with your application and also handed out to other developers for their clients to authenticate the server...

this certificate will be required to be used in the client application to authenticate the server during SSL/TLS handshake

this is basically certificate pinning

darwback: depending on the size of the clientbase it will become challanging to replace this cert

case with 2 certs:

same as above, but the self signed cert is actually a root cert that can be used to sign other certs, in this use case in particular: the server cert...

the self signed root cert can then be used by the client to verify that the root cert was used to sign the server cert, which makes replacing the server cert easier ...

you might want to do the later and also setup a certificate revocation list in case you need to invalidate a cert ...

-Every client can have same client side certificate.

all the client needs is (as @john already pointed out) the self signed server cert (case 1) / self signed root cert (case 2)

-Visiual Studio Command Prompt is enough to create these certificates.

please notice that the documentation of makecert states "The Certificate Creation tool generates X.509 certificates for testing purposes only." apparently this limitation was lifted ...

2
votes

I think what you are after is called certificate pinning.

SSL certificates are used in the following way by default:

  • Certificate is issued by some authority. Client (browser, operating system such as Windows, Android etc) has a list of authorities it trusts. If certificate is valid (not expired, issued for domain we are connecting to etc) and is issued by trusted authority - all is fine

  • There are a ton of different authorities and client cannot trust them all. Instead, it trusts certain selected "root" authorities.

  • Those "root" authorities delegate ability to issue certificates to other, smaller, authorities, to which those root authorities themselves trust.

  • This might go on, so there is a chain of trust: certificate is issued by authority A, which is trusted by authority B, which is trusted by "root" authority, which in turn is trusted by client (your operating system).

That model has several weak points, one of them is list of "root" authorities your client trusts. Someone, like your corporate admin, or your government, or ISP provider, can install or force you to install custom certificate to your trusted "root" authorities list. Then it can perform man-in-the-middle attack by intercepting your SSL traffic and reencrypt it with this custom certificate that was installed to the trusted list.

That way client will think that all is still secure, while in reality your traffic is intercepted and responses are recorded and\or modified.

If you don't like this - you can use certificate pinning. Idea is simple - you just embed expected certificate for your api endpoint in your software.

By doing that you don't any more need to trust any authorities or verifying chain of trust above. All you need to verify is that certificate presented during SSL handshake is exactly the same as you embed into software.

For that reason - you don't really need certificate issued by some authority and you can use self-signed certificate.

So if you follow this path - issue self-signed certificate and embed it (without private key of course) to software (send to clients) and instruct them to verify your server certificate presented during SSL handshake is exactly this certificate.

Drawback is of course that if your certificate is compromised or expired - you need to update all software. It's not a big problem if said software is controlled by you, but it might be a problem if software is controlled by third party.