I'm trying to modify my Go client and server code to use TLS. In Python I can do ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
which will automatically load the system's trusted CA certs and uses secure settings. I'm wondering if there's something similar in Go where it will automatically load trusted CA certificates. I'm not sure exactly what to put for the client's certificates.
I think you're looking for tls.Config. But keep in mind that Python's ssl.create_default_context exposes a lot of SSL internals that most people don't need, and you might not need a tls.Config in your application at all. For instance, net/http has a http.ListenAndServeTLS() function which starts a TLS web server with sensible defaults and whatever certificates you provide.
Related
Context:
I have an application that is deployed to each client as a Virtual Machine. The latter is installed by the clients wherever they want (I don't necessarily know the final domain). The application comprises an JBoss Web Server that provides access to a configuration page, protected by SSL. Right now the server is using a self signed Certificate. However, I want the browsers to stop showing the warning messages associated to self signed certs. Moreover, I provide a free version of the application that has basic functionality.
Question:
For cases where the client is using a free version (and me wanting to reduce costs), what is the best approach when using a SSL cert, and not knowing the final domain (most of the time)?
It is acceptable to use a self-signing cert? If so, a different one
per client install?
Is it best to issue a new cert (maybe a free one) for each
deployment?
Is is acceptable to use the same cert, signed by a proper CA, on all
of the deployment VMs?
A completely different approach?
Thanks guys!
It is acceptable to use a self-signing cert? If so, a different one per client install?
Ask your clients. Will they put up with a browser warning? or not?
Is it best to issue a new cert (maybe a free one) for each deployment?
It is best for the client to acquire his own SSL certificate. You can't do that for him. Nobody can.
Is is acceptable to use the same cert, signed by a proper CA, on all of the deployment VMs?
No, it entirely defeats the purpose. The certificate and the private key it wraps are supposed to uniquely identify the holder.
A completely different approach?
Handball the whole megillah to the clients. Self-identification is their problem, not yours.
I'm looking to configure wcf to transport data from one web server to another web server with exactly one service host and exactly one client.
Is there a simple security configuration available that does not require x509 certificates?
Additional info:
I may be looking for a simple configuration (message is okay) that could use a predetermined username / pw / enc, etc. I'd also like to avoid sending a password in cleartext.
If by "simple security configuration" you mean encrypting the transmissions between the end points, there's no simple, easy way without using x509 certificates, short of creating some kind of elaborate VPN connection point to point.
But using certificates with WCF doesn't have to be painful or expensive. Using message-level encryption (xml based) is easy enough to configure and get running, and since the communication is always between points "A" and "B", the obvious problems associate with using message encryption (distributing the certificates) isn't a problem at all.
The steps would be:
-Generate a self-signed x509 cert with public and private keys and copy to both servers
-Configure your clients and host to use message security
-install certs on both servers (plenty of documentation available, like this one)
-Configure your host and clients to find the certificates during startup
-run and test
After you've got everything running, you'd obviously replace your self-signed cert with a commercial version.
You didn't mention your platform. Are you on Windows? If so, you can use Windows credentials with message-level encryption and no need for certificates. Here is a step by step guide on how to do it.. Hope this helps!
I am new to TLS/SSL so this might be a very basic question, but I've been searching a lot an could not find an answer.
I am trying to implement a TLS/SSL client. This client will run on an embedded unit with Windows OS on it (XPe or WES7). My implementation uses GnuTLS.
How do I get the list of trusted authorities to my unit so my client can verify the server's certificate? Is it supposed to be a file stored on the client side, that the client is responsible for keeping up to date? Or can my client somehow get this list from the internet each time it is needed and not maintain it locally?
The Certificating Authority (CA) master certificates are stored client side and the client is responsible for keeping them up to date. Keeping them up to date isn't as hard as it sounds, as CA certificates aren't changed that often - most are valid for 5-10 years at least.
Client side storage is necessary because any given internet site your application uses might be compromised.
To get a list, you might start by looking at the CA certificates distributed with a browser or at the cacerts file distributed with Java. Before releasing your code, you'll probably want to check that the certs you use are genuine by checking them against information provided by the CA.
Go to any Windows machine and run "certman.msc" from command-line. Export each CA certificate (Intermediate Certificates, Trusted Authorities) to file (BER, PEM), then import these certificates into your embedded software. Now you can validate email certificates, the same way Windows does (i.e. using various x.509 related RFCs and CRLs)
I have a web service which is secured through HTTPS. I also have client software which talks to this web service, using libcurl (which may be linked to OpenSSL, or linked to GnuTLS; I don't know which one, it depends on how the user installed libcurl). Because the web service is only ever accessed through the client software and never through the browser, the web service utilizes a self-signed certificate. The client software, in turn, has a copy of this self-signed certificate and explicitly checks the connection against that certificate.
Because of Heartbleed, I want to change the private key and certificate. However I want my users to experience as little service disruption as possible.
For this reason, I cannot change the key/certificate on a fixed date and time. If I do this then all users must upgrade their client software at that exact date and time. Otherwise, the upgraded client software won't work before the server change, while old versions of the client software won't work after the server change.
Ideally, I want to tell my users that I'm going to change the certificate in 1 month, and that they have 1 month time to upgrade the client software. The client software should be compatible with both the old and the new certificate. Then, after 1 month, I can issue another client software update which removes support for the old certificate.
So now we've come to my question: can I append the old certificate and the new certificate into a single .crt file? Will this cause libcurl to accept both certificates? If not, what should I do instead? Does the behavior depend on the SSL library or version?
Tests on OS X seem to indicate that appending both certificates into a single file works, but I don't know whether this is OS X-specific behavior, or whether it works everywhere. My client software has to support a wide range of Unix systems, including Linux (multiple distros) and FreeBSD.
Short answer: You can't.
Long answer:
Yes you can put multiple certificates in a single .crt file, regardless of platforms.
However HTTPS can only serve one certificate, instead of a crt file. So it's not the file that is limiting you, it's the protocol.
You could have a look at SNI https://en.wikipedia.org/wiki/Server_Name_Indication
to be able to serve another certificate based on the SNI information sent by the client at the beginning of the SSL Handshake
Alternatively, you could use a separate TCP port (or IP, or both) that will serve the new certificate.
But you say
The client software, in turn, has a copy of this self-signed certificate and explicitly checks the connection against that certificate.
This then requires you to release a version of your software for your clients to run, to at least have the copy of the new certificate you are going to use.
I guess you should better use a certificate signed by well-known CA, to decouple your server certificate from its validation chain, but that indeed means paying.
Yes a cert file should be able to hold multiple certificates. I would expect this to be broadly supported.
I have academical project to build communicator with Public Key Infrastructure. For communication between server and clients I'll use SSL/TLS and I need for them certificates. I have to build Certificate Authority with CRL and I can do this with openSSL but this tool is only good for manual administrative not for making certificates automatically in remote CA.
To be clear: Clients must register and login to communicator using certificates but it should be made invisible for them. I've tried running openSSL as process in Java but it's not working properly - my previous problem.
Have you any good advice for making simple PKI?
You can use and extend EJBCA. It takes some getting used to but it has support for some HSM's, and it should not be hard to create a small PKI with it. Open source.
A replacement for simple operations of OpenSSL, would be Bouncy castle. To have better CA support you should also use the EJBCA.
To create certificates automatically in the client (I assume you use a client web browser) is a bit trickier. Some browser can generate private client keys and then get them signed by the CA server.
Generating client side certificates in browser and signing on server
In that case, I would also use the EJBCA to make it manageable.