I want to set up secure TLS for my docker hosts as described here which describes creating your own Public Key Infrastructure (PKI). For production servers it is inadvisable to use your own Certificate Authority. Are there any online Certificate Authorities that can provide the public/private keys (.pem and .csr files) for me? I have been looking at Lets Encrypt, as I know they can provide SSL certificates, but I cannot find any guidance on providing a PKI.
Edit:
This is the setup I'm attempting to create:
Can Let's Encrypt or any other online service, provide the necessary key/cert files as represented in this image.
You can use Ascertia services to setup your pki structure.
https://www.ascertia.com/
They have a full PKI standard service for CA and Key Management.
Related
I have to add a SAML implementation on a project. I decided to use Spring SAML.
I'm able to generate an Service Provider metadata file and I have to send this file to the IDP (this IDP uses ADFS) but I don't know if I should create an auto-signed key or CA signed certificate for our SP metadata file.
According to this link, the best practice is to generate a self-signed certificate (x509 certificate). But I also found some topics which advice to use a CA signed certificate.
But I can't find anything on the specs.
What's the best practice ?
And if I should use a CA signed certificate, how can I obtain it?
Thanks to All
SAML2 uses certificates just as a convenient way to handle signing and encryption keys. The SAML2 specification even states that it cannot be asumed that the certificates hasn't expired or is issued to any relevant host name.
So that's what the specification says. But in reality some IDP or SP operators require the certificates to be valid.
I'd suggest that you talk to the Idp operator and ask if they have any requirements. If they don't, go for a self signed cert.
I'm reading about certificate-based authentication in SSL, and got a question about this process. (picture is taken from above link)
Question is: why server.cer and client.cer are not secrets. In this diagram, it seems that communication hasn't been encrypted when certs got exchanged, does this mean both certificates are exposed in plaintext? If so, why it's secure? Because in this way an adversary can easily obtain server's public key as well as its certificate, and impersonate the server. I think I misunderstood something. Please correct me.
Because in this way an adversary can easily obtain server's public key as well as its certificate
Correct.
and impersonate the server.
Incorrect. You need the private key as well as the certificate to impersonate the server.
The diagram you quoted isn't correct. Both sides will have not only a keystore but a truststore. The incoming certificates are checked against the local truststore; the outgoing certificate comes from the keystore.
given that the certificate is used to verify the public key belongs to the server
No. The certificate plus its digital signature is used to verify that the certificate belongs to the server. The digital signature is created with the private key. See the article you quoted.
However it isn't entirely correct. In the diagram, incoming certificates are checked against a local truststore, which is separate from the keystore. The session key is never exchanged (2.1 step 5).
I have a small question about GPG certificates and certificates authorities.
I am using GnuPG to sign a tarball that I am hosting on my server. I would like that users who wants to download this tarball to be able to encrypt it using my public key.
At the moment, I'm storing my public key on another server that I own. There are 2 issues with this:
The key isn't "trusted", and the user get a warning
In the same idea, because the key isn't trusted, if the key is maliciously changed, the user won't see anything
I've read a bit about cryptography solutions in the past, and know a little bit how X.509 CA work, but I don't really understand how it is for PGP keys. I've tried to use my SSL (trusted) certificate in GPG, but it always fails (maybe there is an option I haven't found?).
If it's not possible to use my SSL certificate, how can I "register" my PGP certificate to a CA?
Thanks!
Best,
Thibault.
For all practical purposes, X.509 certificates and OpenPGP key pairs live in separate worlds. X.509 certificates are trusted hierarchically (building certificate chains) and OpenPGP keys are trusted on peer-to-peer basis.
As the technologies are incompatible, they are not easily replaceable by each other. To let users trust your OpenPGP key, you can publish it in one of OpenPPG key repositories (keyservers), and hope (or suggest) that users do use it as a trusted source of OpenPGP keys.
Alternatively, you can use your server's certificate to create a detached PKCS#7/CMS signature of the archive you distribute, but unlike OpenPGP there are no widespread tools available to check PKCS#7/CMS signatures on end-user computers. (Well, maybe OpenSSL will work for your user audience.) Note that KeyUsage of the server's certificate probably won't be appropriate for signing, so the users will get a warning.
Please note that OpenPGP keys are called "keys", and X.509 certificates are called in this way too. There exist no "pgp certificates" as well as no "ssl certificates".
I'm writing a simple client and server using Go. I don't want to pay for an SSL certificate, and I've read that self-signed certificates are useless for proving identity since an attacker could just MITM and provide his own self-signed certificate.
However, I've learned that I can have my client use whatever root certificates I want. Can I just create my own, have the client trust that, sign a certificate for my server, and connect securely while being protected from MITM attacks? If so, how do I create my own root certificate?
A self-signed certificate is a special case of deploying your own PKI (pushed to the extreme where you only have one certificate in that PKI).
Both can be used to prevent MITM attacks, provided that the client can verify the server certificate using trust anchors (certificates) it knows in advance (and has been configured with them in a trusted manner).
You can create your own CA and configure your client to use its root CA certificate or, if you only have a very limited set of servers, you can usually configure clients to trust a specific certificate directly (self-signed or not).
You may be interested in these questions for links to tools:
Solutions to sign certificates
Recommendations for a Certificate Management tool for Linux
OpenSSL's CA.pl (useful, but may lack general management interfaces)
Once you've understood the basic principles, the technical aspects are not necessarily difficult, but part of the real difficulty is in the administration of your CA.
Firstly, Thanks to all those patient techies trying to help unknown people.
Secondly, I have a wcf service which should be consumed by only several clients (10) known to our company. This wcf service has the x509certificate "CN=ABCD". Now it expects to receive a certificate in turn from clients to consume this service. So here are the design questions
Should I create one certificate
"CN=ABCD" , then right click on it
and export as pfx files and
distribute them to Clients?
Some say to validate in code and
some say to validate in config which
is better?
How should I know which client is
calling as the certificate has same
name for all if my company
distributes it?
what is the difference between .cer
file and .pfx file?
When passing the certificate to
clients, will I be giving both .cer
and .pfx files?
How should I be revocing only one
client if it expires?
My comapny already has a certificate
like *.fdfd.org . Can I use this as
my X509Certificate instead of
generating one?
Many questions! But due to lot frustration, I wanted to have the opinion of developers out there because I couldn't get the right info.
NO You must have separate certificate for the service and you should have one certificate for each client. Once you share private key of your service your security has gone.
You can either install public keys of client certificates to Machine\Trusted people (client with any trusted certificate will have access to your service) or you can use custom certificate validator (only message security - according to your previous question you probably use message security) to validate really only those 10 certificates.
This is only possible if you create separate certificate for each client. It is also possible to combine certificate with supporting user name and password but it requires very advanced WCF configuration and still sharing single certificate among multiple clients is a bad decision.
Certificate is just container for some information - keys for asymmetric encryption. .cer contains only public key which can be freely distributed - you will probably have to distribute .cer file of your service's certificate among clients. .pfx contains both public and private key and must be secured as much as possible. Once .pfx file is compromised the certificate is not secured any more and must be replaced. Because of that you must keep your service's .pfx (installed in certificate credential store) and each client must keep his .pfx.
If you create certificate for clients you will pass at least .pfx to them. Obviously once you send such certificate by unsecured email you seriously hurt the security.
If one client expires you will remove its certificate from trusted certificates. If you have your own certification authority (which you should have if you want to create certificates for clients)
If your service sits on fdfd.org you can probably use it but only for the service.