i am a student and i have an assignment to do which involves Digital Certificates.I literally know very little about this topic and my project that i have to do is:"Create a GUI program(System) that authenticates users based on their digital certificate" .Now, That's the whole project request , and i looked a little(too much i must say) and literally found nothing that could help me .Researching i found out that the most basic certificate is X.509, so i d like to write a simple maybe java gui program that could solve my problem, if someone can help me , please do! Thanks in advance!!
If you do not know how certificate based authentication works, here is some information you shall need to read.
https://www.networkworld.com/article/2226498/infrastructure/infrastructure-management-simply-put-how-does-certificate-based-authentication-work.html
You should discuss with the person where assignment originated what sort of UI they expect and how the client would send the certificate to the server for authentication.
X.509 is a specification. All certificates conform to the specification to ensure that systems can work with each others certs. However you can maintain the certificates in many different formats.
A real life use case of this could be a terminal program that sends your personal key to the server and the server program opens up a session for you.
Related
Sorry in advance if this question has been posted before. I have look around but couldn't find an answer.
I am creating a server in Java that has a SSL socket to accept clients. I have been looking around on how to create the socket and have started to add the code to my application. After looking around the find out how to allow a self-signed certificate for testing I found that I create a keystore and add the certificate to that. To use the certificate I would need to add "System.setProperty("javax.net.ssl.keyStore", "keystorename.jks")" The only problem is I have to specify the password in the code as well if I go off other developers examples.
I would like to know if I have to specify the password and if I do need to what is the security implications?
Thanks in advance,
Yes you do, and the security implication is that the password is (1) fixed by the code and (2) probably visible in the object code. The solution to (2) is ultimately physical security of the software and the host it runs on.
Is it possible for a java web application to get digital certificates installed in Browser. What I am looking for is I will read the digital certificate from the browser and based on the certificate, I will give certain access. I tried to search in stackoverflow but did not see any similar questions.
To make things more clear, we have users have company issued laptops and has company specific digital certificates installed. Now my web application should allow or deny access based on whether these digital certificates are available. From the browser I can see the certificates as shown in the following image
I am looking for some method like getting all the certificates based from httpservletrequest(i know its not available, but just giving reference so that someone can point out if api of some sort is available and if it is really feasible/). Read the certificates one by one and get details like who issued it, what is the expiration date, CRL Distribution points, etc.
I know it may be a dumb question and may have security flaw, but still going for it.
I have some websites that redirect the user login to https, some user get scared when they see the warning as it says the site is not trustable or someone is trying to intercept their communication, so most of the users do not continue with the login procedure.
The fact is that i would like to avoid paying the big amount to get a valid certificate from one of those companies, as i am not making money with these sites, but i would like to keep the users credentials secure. is there a way to avoid this?
It would be enough if i can intercept the https redirection and display a message to the users explaining the situation.
Some widely accepted certification authorities offer a free certification path for Class 1 certificates (which make no assertion over the identity of the certificate owner, only that they control the subject; in reality, few people actually check SSL certificates for identity verification, so this is rarely a realistic concern—and given the non-commercial nature of your application, may not be a concern at all in this case).
One such certification authority (that I have used myself in the past) is StartCom.
No, you can't hide the message without using a cert that is endorsed by a recognized CA. That's a fundamental fact of internet security.
What you CAN do is, before that message comes up, explain that they will see the warning. You can tell them that in fact your self-signed certificate is not vulnerable if a CA gets hacked (which has happened), while the rest of e-commerce is compromised.
But they won't read the long explanation. The best you can do is prepare them and tell them that ONE TIME they have to trust that you are who you say you are.
This question may seem like a novice, and perhaps 'stupid' question but please bear with me...
I'm still struggling to find a way to get my Java application to use a keystore located inside the JAR file, and I'm very tempted just to disable certificate validation all together using the method here. However, before I do so, I just wanted to confirm why you should not do this and whether those reasons actually apply to me.
I've heard that no certificate validation can make your application liable to "Man In The Middle" attacks (I think), but even if I am correct, I am unsure as to what these actually are so please could somebody explain. Though, if they are what I think they could be, I'm not sure whether my application ever be subject to them because, my application only uses an SSL connection to obtain data from my website, so users do not tell the application which URLs to visit - if that makes sense...
Here's, an attack scenario. Other's might want to contribute some more.
Your application accesses a URL. At some point along the way (any intermediate network hop), an attacker could position himself as a "man-in-the-middle", that is, he would pretend to be a "proxy" for your communication, being able to read everything that goes through, and even modifying it on the way: the attacker could act on behalf of the user, mislead him as to what information he gets, and basically access al data being transferred.
Enter SSL: your client receives a certificate from the server, with a valid key (Signed by a known certification authority, or present in your keystore). The server will then sign and encrypt all it sends using that key. If an attacker where to place himself in the middle, he would not be able to read the data (it's encrypted) or modify it (it's signed, and modification would break the signature). He could still block communications altogether, but that's another story.
So that's that... if you ignore your keystore, you can't verify any server side certificate, and you open the door to man-in-the-middle attacks.
Though, if they are what I think they could be, I'm not sure whether
my application ever be subject to them because, my application only
uses an SSL connection to obtain data from my website, so users do not
tell the application which URLs to visit - if that makes sense...
If you connect to a server via SSL and you don't do any authentication, effectively you are have no security.
You have no idea who is the endpoint you are talking to.
The fact that the user does not type in a URL, but the URL is a hardcoded URL to your site is irrelevant. A simple proxy that forwards the data from your client to the server can steal all your client's data since there is no kind of authentication (this is the Man in the Middle Attack).
I would suggest you put the code you are using to load the keystore so that you get help on that.
Otherwise, if you don't have any requirements on security and you don't have any sensitive data you should go for plain connection (i.e. non-SSL) so that your performance does not deteriorate due to the unecessary (in your case) SSL overhead
I have a process that runs on a UNIX (Solaris) server that runs nightly and needs to be able to send out encrypted emails.
I only need the "encryption" portion, NOT the digital signature / self-repudiation part of PKI.
I use MS Outlook in a corporate setting and I am assuming that when a user clicks "Publish to GAL..." under Tools -> Options -> Security, this will publish their PUBLIC KEY to the Global Address List (GAL).
So I am thinking that I need a way to connect to the Exchange Server that the GAL is on from my UNIX server.
Then I would need to retrieve the recepients PUBLIC KEY.
Then I could encrypt the email using the recepients PUBLIC KEY.
This would encrypt the email and only allow someone with the recepients PRIVATE KEY to read the email right?
Then I would send out the email.
But, what I am not sure about, is how to encrypt the email using only the recepients PUBLIC KEY (no KEYS on the UNIX side) in a way that MS Outlook will be able to read the email when the recepient receives it?
Would this work?
Anybody out there run into a similiar problem and come up with a solution?
Java code is preferred, but any langauge would do to start with.
Any additional details required in order to get a reasonable answer?
Thanks
You're logic is right.
Typical PKI encryption is:
cryptoAlgorithm(plaintext, public key) = ciphertext
cryptoAlgorithm(ciphertext, private key) = plaintext
For some algorithms, the cryptoAlgorithm is the same procedure, sending and receiving.
So... for each recipient you need their digital certificate, which will contain their public key.
GAL Certificate Storage
I would think it would be possible to configure the GAL to allow users to publish certificates. My general impression is that how the GAL is configured and used varies from company to company.
S/MIME & PGP
I agree with the post that S/MIME is what you want for Outlook.
Also note - if your users are using Outlook Web, rather than the Outlook client, they won't be able to receive encrypted emails. At least as of 2000, but I suspect 2003 as well. It's a huge usability problem and I've got no good workaround.
General Microsoftyness
Microsoft has their own special way of doing things (no kidding...). They are
no different in the world of PKI. User certificates must be clearly marked with an encryption capability. I know it must have the KeyUsage field KeyEncipherment. And there may be one other extension required by Microsoft. Having an incorrectly formatted user certificate could mean that the recipient will be unable to read the mail when it arrives, because Outlook won't agree on the fact that the mail was encrypted. Spare some serious integration testing time here and plan to hit lots of user groups on how to do this. Every time my team has had to integrate with a Microsoft product, there have been nasty surprises, particularly regarding how the certificate is configured.
Libraries & Tools
I second the recommendation for BouncyCastle - I haven't used it, but people I trust swear by it. I personally loved the Phaos toolkit when I had to write this stuff, but I'm out of date. I know it cost serious money, and may be too much bang for your buck.
OpenSSL is another fabulous tool, and useful for much more than SSL. It's great for generating test certificates, but I can't remember if it does S/MIME email encryption as well.
For most libraries, you should be able to take plaintext, and the certificate, and put both into a function that generates the S/MIME message. They may require the encryption algorithm as well.
In the general case : to send an encrypted message to someone, you only need their public key. You dont need to have a key yourself. The rule with asymetric crypto is whatever is encrypted with a public key can be decrypted with the corresponding private key, and whatever is encrypted with a private key can be decrypted with the corresponding public key.
You will need a key for your server only if you want to sign the message.
If you want to do the implementation in Java, I dont think that JavaMail supports encryption out of the box, but you can have a look at JavaMail-Crypto (havent used it myself). There is supposedly a JNI interface to GnuPG somewhere ... And you can always exec PGP or GnuPG from any language ...
I dont know about the support for PGP in Outlook, nor anything else about Outlook.
You have to send encrypted mail to Outlook in s/mime format. Outlook doesn't support PGP.
Start by trying to send a plaintext message from Java and see if you can get it into Outlook. Worry about the encryption later. Use the JavaMail library to create and send emails.
I don't know how to extract keys from the GAL. It is probably easiest to start off by exporting a key manually and see if you can work with it.
To create encrypted mails in s/mime format I recommend Bouncy Castle. Bouncy Castle is a crypto-provider that also has support for s/mime. (Look for the CMS/Smime package). There should be some examples in the downloaded sources. I've used it in the past to send emails to a wide array of email clients, including Outlook and it works pretty well. But brace yourself for the crypto stuff -- it can be a steep learning curve!
The caveat not noted previous is that the GAL isn't necessarily on the Exchange Server, and is more frequently found on the Domain server, when not run in a standalone mode. The certificate will be found in the LDAP attribute userCertificate or userSMIMECertificate.