I am new to SSL and Certificates . I have been doing my research about client certificate authentication. I have read this and wiki.
So If I have to implement a client certificate auth solution for my B2B REST service should I do following
Ask clients to generate their own private-public key and generate certificate (CA issued?) for their public key. Send that certificate over email or USB key.
On the server side import client's public certificate into trust store and enable client authentication
During the hand shake client presents it's certificate and gets authenticated, because server has a copy of cert in it's trust store and can verify CertificateVerify message
My question is how does it stop anybody to pose as my client. Let's say a hacker X sends a CA issued certified to the server as part of handshake. Then server would automatically trust it and grant access.
Client Cert based authentication doesn't actually verifies if the client connecting is in your whitelist.
Lets say client X gets a cert from public CA Y, and you import Y's cert in your trusted list, then the connection from X will succeed.
Now, if a intruder Z buys a cert from same CA Y (knowing what CA your application would trust is a complex part), and tries to authenticate with your application, the verification would still succeed, because its a valid cert from a trusted CA. The application would continue to serve contents to Z, which you dont want.
So the best approach is to self sign client clients cert(and deploy it on clients you trust) and you will be the CA in this case, which limits the intruder from gaining access.
Here is some reference,
# Create the CA Key and Certificate for signing Client Certs
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
# Create the Client Key and CSR
openssl genrsa -des3 -out client.key 1024
openssl req -new -key client.key -out client.csr
# Sign the client certificate with our CA cert.
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt
If you just want to allow only a few known IP addresses, then a network based IP blocking/Throttling is the preferred approach( but, has its own complexity of managing/updating IP list).
I've to break down your question into two parts.
Part one: Let's say a hacker X sends a CA issued certified to the server as part of handshake. Then server would automatically trust it and grant access.
If X aquires the client certificate of an authentic client then that's ok. Because the certificate itself does not contain any secret. Those certificate can be published anywhere without doing any damage (Except if you want to keep your email address a secret, try not to publish it. But it may will get out there after some time. And company crafted X509CertificateExtensions are not considered as well.).
The private key is the important key which must be kept secret by your client. If X gets the private key as well, X can impose an authentic client and login into your system. Therefore clients must protect those private keys from getting stolen!
That's because within the client-auth handshake, the server not only requests the client certificate. The client must also prove that he's the real owner of the certificate, by using his private key as stated in the wiki you referenced: The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. Such a signature can only be done if the client posesses the private key belonging to the certificate, as stated in the wiki as well: This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.!
Part two: How do establish a initial trust relationship?
That part is difficult if there are many clients involved. That's why the PKI was established. You trust the CA, and the CA should to the identity check on that clients who request a certificate.
For homebrew solutions in which case you have your own CA, or you don't trust a CA, the part is up to you.
You must be sure that you grand access to your services only to authentic clients. If you do this via USB keys and the clients hand them over to you in person, that's ok.
If you receive an email which says "hello, i'm your friend XYZ from ABC, remember? Btw. here's my certificate" - check it twice.
Related
I have created a SSl certificate using these commands:
openssl genrsa -out kc_ca-key 2048
openssl req -new -out san_domain.csr -key kc_ca-key -config openssl.cnf
openssl x509 -req -days 3650 -in san_domain.csr -signkey kc_ca-key -out kc_ca-cert -extensions v3_req -extfile openssl.cnf
openssl.cnf file contains the common name, country name, subject alternative name and all such information.
In browser, I am able to connect securely after importing this certificate but when i run curl command with same certificate, i get the following error:
NSS error -8156 (SEC_ERROR_CA_CERT_INVALID)
* Issuer certificate is invalid.
* Closing connection 0
curl: (60) Issuer certificate is invalid.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
How to resolve this error
There is not enough information to determine what your problem is.
I am making the following assumptions:
You sent the certificate request (CSR) to a CA provider and got a certificate back.
You setup some sort of web server with that certificate
I am also assuming that you used a "Windows" web browser like IE or Chrome that uses the windows certificate store to test the certificate.
The CA that signed your certificate is a well known CA that has there root certificates in all the common CA Lists.
If the above is true and a web browser like Firefox (that uses it's internal CA list) fails it's because the web server is using a certificate without any intermediate certificates.
You need to go find the intermediate certificates for your CA signed certificate, combine them into a certificate chain and setup your web server with this certificate chain. The details of how to do this will depend on your web server.
Once the web server is setup with a correct certificate chain then your curl command (and firefox) should work fine.
The reason that windows works fine is because windows keeps a list of common intermediate certificates that it can verify a certificate chain with. A openssl based client doesn't, so the intermediate certificates have to come from the SSL socket server (e.g. web server) down to the client to be able to verify the certificate chain back to a trusted root certificate in the client CA list.
I do have private key(my_ca.key) and public key(my_cert.crt) which is signed by DigiCert. Now I want to generate the SSL certificate (version 3) and sign it by my private key . Here is the way I tried to do that. But when I export into keychain (Mac OS X). I have been getting error like this "This certificate has an invalid issuer keychain". No idea how to solve this. Here my_cert.crt is extended from DigiCert High Assurance CA-3 and that one extended from DigiCert High Assurance EV Root CA. Also added DigiCert High Assurance CA-3, DigiCert High Assurance EV Root CA into keychain. It shows my_cert.crt is valid. How would be getting this kind of error.
######### Initialization
SSL_SUBJ="/C=LK/ST=Colombo/L=Colombo/O=wso2/OU=laptop/CN=mdm.go.com"
########SSL Certificate
echo "\nGenerating SSL Certificate >>>>>> START"
openssl genrsa -out ia.key 4096
openssl req -new -key ia.key -out ia.csr -subj "$SSL_SUBJ"
openssl x509 -req -days 365 -in ia.csr -CA my_cert.pem -CAkey my_ca.pem -set_serial 765644787 -out ia.crt -extensions v3_ca -extfile ./openssl.cnf
echo "\nGenerating SSL Certificate >>>>>> END \n"
openssl pkcs12 -export -out ia.p12 -inkey ia.key -in ia.crt -CAfile my_cert.pem -name sslcert -passout pass:password
Note: added custom entry in /etc/hosts mapping IP address to SSL certificate CN and for testing server and client are in the same machine.
Download
https://developer.apple.com/certificationauthority/AppleWWDRCA.cer
and double-click to install to Keychain.
Select "View" -> "Show
Expired Certificates" in Keychain app.
Confirm "Certificates" category is selected.
Remove expired Apple Worldwide Developer Relations Certificate Authority
certificates from "login" tab and "System" tab.
Here's Apple's answer.
Thanks for bringing this to the attention of the community and
apologies for the issues you’ve been having. This issue stems from
having a copy of the expired WWDR Intermediate certificate in both
your System and Login keychains. To resolve the issue, you should
first download and install the new WWDR intermediate certificate (by
double-clicking on the file). Next, in the Keychain Access
application, select the System keychain. Make sure to select “Show
Expired Certificates” in the View menu and then delete the expired
version of the Apple Worldwide Developer Relations Certificate
Authority Intermediate certificate (expired on February 14, 2016).
Your certificates should now appear as valid in Keychain Access and be
available to Xcode for submissions to the App Store.
You can also check on https://forums.developer.apple.com/thread/37208
For more detail refer https://developer.apple.com/support/certificates/expiration/
I have got a simple solution for this problem.
Select the certificate in keychain right click it. There you will see the option "GetInfo" click it and select "Trust" option. Select the option When using this certificate to "Always trust". That's all - this certificate will be marked as trusted for your account.
Normally all X.509 certificates in certificate chain except the last one are CA certificates. The first certificate in chain is called root CA (in your case DigiCert High Assurance EV Root CA), then other CA certificates in issuer chain (if any) are intermediate CAs and the last one is End Entity (not CA). I don't think you can issue new SSL certificate issued by non-CA certificate. So you can use my_cert.crt signed by DigiCert as SSL certificate but you cannot issue your own using my_ca.key.
I'm setting up a mysql server and am trying to have a mysql client connect to it over SSL. I'm going to be using a self signed certificate for the same. Reading the MySQL documentation on setting up SSL I see that I have to specify the path to the following files :-
the SSL root CA
the SSL certificate
the SSL private key
In this particular case, should I be setting both the root CA and the certificate to my self signed certificate?
Example of how to create properly a Self-Signed SSL Certificate.
Su to root and create a directory that only the root account has access to.
su -
mkdir certificates
chmod 700 certificates
cd certificates
Use openssl to generate a server key
openssl genrsa -des3 -out server.key 4096
Openssl will request a pass phrase. Type in a sentence that is long and complex but that you can remember (you'll have to type it at least twice). Try to make it at least 40 characters long, with punctuation and capital and lowercase letters. The more different characters you use the better.
Then create the certificate signing request with the server key you created in step 2.
openssl req -new -key server.key -out server.csr
Sign your certificate using SSL.
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
You can set your certificate for any number of days, but I recommend 365 so that you remember to update it once a year.
Once you're done, you'll have the following files:
server.crt: The self-signed server certificate
server.csr: Server certificate signing request
server.key: The private server key, does not require a password when starting Apache
Place those files where they are required for your Web server, and turn on HTTPS. (If you don't know how, contact your server administrator.)
We need to provide a secure SSL on our intranet website. Could anyone please help me query below:
Is it possible to get Internal CA signed cert without a CSR?
If above is Yes, how do it generate a Internal CA signed Cert without a CSR.
What am I trying to achieve?
We don't have Production IIS setup. And production IIS will only be setup during the change window. During this change window no resource available to generate CA signed Cert. for a given CSR. Hence, we are trying to create CA signed certs before hand without having to setup the Prod IIS.
The Certificate Signing Request (CSR) is a tool for including a third party in the certificate creation process without divulging your private key. Its essentially a packet of encoded information (including the public key) which can be sent to the third party for signing. The third party receives the CSR, signs it with their intermediate or root certificate, and send back the certificate to you. Your new and shiny certificate file is now a keypair with your private key file. Even better, the third party never had access to your private key through the entire process.
Now to answer your question, yes it is possible. There is no requirement that a third party be involved. Its more a question of how to accomplish this with the cryptographic library of your choice. Check out my post here for a way to get OpenSSL running on windows without admin privileges.
Create a new key and certificate
openssl req -newkey rsa:2048 -nodes -keyout [filepath to key] -x509 -out [filepath to cert]
Create a certificate from an existing key
openssl req -key [filepath to key] -x509 -out [filepath to cert]
You should be able to use OpenSSL to create a CSR independently of IIS (see its req command).
I am in the process of purchasing a Thawte SSL cert to be applied to my slice on slicehost which is hosting my new web app.
Thawte is looking for a CSR.
How do i generate this?
Regards,
Fiona
I doubt you still need this info after 9 months, however...
You'll need to generate an OpenSSL keypair and a Certificate Signing Request.
The keypair consists of two cryptographic keys. A public and private. The public key is included with the CSR along with other applicant information such as name, company, etc. The private key is used to sign the CSR request.
A CSR is what you send to your chosen Certificate Authority (CA) to request that they supply you with an SSL certificate. It includes your identifying information and the public key for your server/site.
Generate the CSR
openssl req -new -newkey rsa:1024 -nodes -keyout example.key -out example.csr
You’ll be prompted to enter information such as Common Name, Organisation, Country etc.
It should be fairly straight forward, but your CA will let you know if you’ve done it wrong, I’m sure.
This will create example.key (the private key) and example.csr (the CSR).
Requesting your certificate
Normally your CA will have a form on their website which allows you to paste in your CSR. This obviously varies from company to company. Once you have given them your CSR, they will first ask you for money, and then generate your CRT file.
P.S. I basically copy and pasted this info from my website, dunno if that's allowed here.