I am developing an app with a server part programmed in Go and a client programmed in C#, the connection between the two is made using TCP socket communication, and to ensure the connection I am using TLS.
My question is whether there would be any security problem in my case when using self-signed certificates for TLS communication.
I understand that for a web server that uses https it is necessary to use certificates signed by a certificate authority (CA) but in my case, when connecting my own client application I don't see why I should use one of these.
If anyone knows anything about it, it would be a great help.
Certificates are used for authenticating the end points, and usually the cert is signed by a certificate authority which your client (such as a web browser) already trusts. Using a self-signed cert in that scenario can lead to problems, as the browser won't trust it, and so will pop a warning box. However, the real issue is that for the typical user, a warning from your server is as good as indistinguishable from an attacker using another self-signed certificate. They'll click-away and KABOOM!
If this is a closed environment, and you control both the server and client, then the self-signed certificate is irrelevant. In fact, you don't even need one at all, and may be better off with one of the alternatives, like TLS-PSK, or TLS-SRP.
Related
when some players enter our game, they meet this error in all browsers
We have changed the certificate recently. So I check one player's certificate on our game page,
It is the lastest certificate. So what may cause this problem? Should we do something after change the certificate?
EDIT1
Did CDN cache the certificate? After we refresh the CDN, some player can connect to the game immediately.
EDIT2
We found the player's browser has such an option "block unsafe certificate", when the option is enabled, he can't connect to the server and he can connect to server when the option is disabled. We export the intermediate certificate and send it to the player for import. After that, the player can play the game with the option selected.
EDIT3
Finally we found the intermediate certificate is right on the nginx side,but on the server side, the ca is missing. After add it, the websocket could work. And When I asked same question on another forum v2ex,I found a good way to test if the certificate chain is complete. you can visit the site and change the domain and port with your site.
https://cert.catbox.io/api/v1/queryChain?domain=s41001-ad-tanwan.zlgl.17tanwan.com&port=8085
If your server is correct, you will find the server side certificate and the intermediate certificate.If you can't find the intermediate certicate, you need to check your server config.
Your server https://s41001-ad-tanwan.zlgl.17tanwan.com/ provides only the last certificate in the chain, the actual certificate of the server.
This certificate is signed by the intermediate certificate from "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" that is valid since 2020-07-16.
If the clients have not updated their browsers/operating systems for some time, they don't have this intermediate certificate, and they report this as an invalid certification authority.
Put the intermediate certificate to the certificate file, and it should fix the problem, since the intermediate certificate is signed by the DigiCert root certificate, that is in the game since 2006. Everyone has it.
You run nginx, right? The ssl_certificate instruction in nginx accepts files with certificate chains. This file should have the server certificate first, then the intermediate certificate.
I have to develop a web application that is both secured over https and uses client authentication certificates. The clients are connecting via invitation, thus it is not intended for users stumbling upon this application by googling around.
The ideal would be to get an intermediate CA certificate form a public root authority and sign both the ssl certificate and use it to issue client authentication certificates. I think that won't work, as simply put I will never qualify for such an intermediate CA (as far as I know, but maybe I am wrong with that).
Second guess: create own Root CA, an intermediate CA and use them. Because of what I wrote about the users, I can embed the necessary certificate chain in the issued certificates. This technically works.
What I would prefer is to get an ssl certificate from public authority and to use my own chain to issue authentication certificates and verify the users. According to this it is possible. But I haven't found anything about how to configure IIS for example (or Kestrel) to request client certificates issued by a specific CA, even less some standard specification where this flow is described.
I am implementing a push notification system for one of my apps, so I am following this tutorial and generating a SSL certificate for that.
This app of mine involves also, some exchange of data between the app and the server and I would like it to be SSL protected and I was wondering of getting a SSL certificate from verisign or other company like that.
My question is: is this SSL certificate created for push a regular SSL certificate, so in that can use it also to establish a https connection to the server (and save a couple hundred dollars to order a third party certificate)? I don't know much about SSL certificates, but I hope it can be used for that...
This will be amazing!
Since each certificate is tied to a specific domain, I'm not sure how this would work. There is a concept of wildcard certificates, but I still think they have to be for the same domain.
In your case, it sounds like you will have the Apple push certificate, which validates the connection between your server and Apple's push notification server. The other certificate would be to validate/secure the connection between your iOS app and your server. Both of these are assigned a different domain (gateway.sandbox.push.apple.com vs. yourserver.com).
One option you do have depending on how your iOS app is structured is to use a self-signed certificate between your iOS app and your server. I'm guessing the end-user will not be seeing the certificate anyway. This might be a way to save you money before deciding on a third party certificate.
Is there a way to create self-signed certificate on IOS programatically?
We have a client-server connection, where the pairing is confirmed just once and then the certificate is used every time to re-establish connection.
right now we're doing it using openssl, but that is a little bit excessive for our needs. does ios have any mechanisms that would
generate the x509 certificate
apply it to socket (ergo create equivalent of SSL socket)
query certificate sent by the server, so that it could be stored to verify server identity?
thank you!
I have a mobile app that will be communicating with my webserver over https. My question is, do I even need to worry about installing a certificate since all traffic to this api will be headless?
In my understanding, SSL provides the encryption for a request, and a certificate establishes trust for the end user. Because these calls to my webserver will essentially be headless, I'm thinking I don't need to worry about the trust establishment.
Am I correct in this thinking?
You will either need a self-signed certificate or a CA-signed certificate in order to use HTTPS on your server.
If your certificate is not assigned to you by a certificate authority, then any connection you make will trigger an error in your URLRequest that you will have to handle. The problem with an untrusted certificate is that a malicious man-in-the-middle could fake data to and from your server with his own self-signed certificate, and possibly pick up authentication credentials or data that he should not have access to.
If you are dealing with any authentication credentials or other private data, I'd recommend just requesting a signed certificate. If you shop around, you can find cheap signed certificates for $10-20 a year, which is a trivial cost to protect your users.
However, if this is just a personal project (the only data you have to worry about is yours), or any data that you will be sending is freely available, a self-signed certificate may be enough.