3 questions:
1.Does anybody know a CA company which allows me to put the bought CA certficate inside SoftHSM (the same as an HSM but without any hardware, this is pure software)?
2.Is it hard to work with the PKCS11 interface? I have a Java application which will sign documents. But I need to communicate through the PKCS11 interface. Anybody had any experience with it before? Is there any tutorial on this?
3.If I buy an trusted certficate, why don't they deliver it in .crt? I have a trial certificate, but my browser just imports it. Don't see where to download this certificate so I can store it my hsm.
Please help to clear my mind.
Late answer, this did not get on my radar before:
Any company should do this. You generate a key pair and create a certificate request. Then they sign your request and give you a certificate. Where you store the private key is normally not their concern. For higher end certificates your identity is though.
If you just need to sign and you have an RSA or ECDSA private key then you can use the Java PKCS#11 provider. You then simply use the standard Signature class after configuration. To configure the HSM right is an art in it's own though.
You can normally export your certificate again, otherwise right click and download. The way it is handled is because of the MIME type. You could also use e.g. wget, which would just download using the link you provide.
Related
So this mobile app I'm working on is primarily in flutter but I have some API callbacks in native Android and Swift that I would like to keep, however the thing is the actual api calls can be to custom servers. After realizing that Flutter cannot read manually installed user certificates on Android, I tried to figure out a way to do it like chrome and ask the user "Do you want to trust this certificate y/n", however I can't figure out a way to do it on Java.
On the flutter side, theres a callback part of HttpClient called badCertificateCallback, where if anywhere in the app a certificate is unsafe it will automatically refer to there no matter where the certificate is called, currently on the flutter side I have it set so that if the user trusts a certain link, it will trust that certificates information, is there something similar on Android I can do? Most of the other solutions I found wanted to either trust all certificates which isn't ideal or required the user to have a cer file somewhere.
You have several ways that you can go:
Either you add your self-signed certificate to your client's truststore.
Or you use your own certificate authority to sign the server's certificate signing request (CSR) and add that certificate authority's certificate to the truststore of your client. Even here you could decide to just add the server's certificate to the truststore directly, but then why did you use the CA?
Or you use an official certificate authority (let's encrypt, geocerts, digicert, ...) to sign the certificate. Since the official certificate authorities are already installed in your client's truststore, no additional step would be necessary.
Short answer: You will not succeed without a certificate. But it does not have to be a .cer file.
Since you are denying the 'no certificate check/trust all': checking certificates is the better way, even if you use a self-signed certificate. But the client needs something to check against, and that data usually is transported in certificates. You can store such a certificate in different file formats. Check this page: https://www.ssls.com/knowledgebase/what-are-certificate-formats-and-what-is-the-difference-between-them/
I have registered a certificate in AWS IoT core. The next step is to create a thing and attach this certificate to the thing. My requirement is that the certificate's common name must be the name of the thing to be created. Does anyone know if there is a way to fetch the common name of the certificate? If yes, could you please help me out here. Thanks in advance :)
P.S. I am trying to do this in Java
If you know the certificate ARN, you could use the CLI command "describe-certificate" to get the entire certificate, and then use a Java library like BouncyCastle to parse the certificate for its common name.
It might also be possible to do what you want without ever parsing the certificate directly yourself using just-in-time-provisioning. This process lets you set up a CA certificate so that anytime a certificate issued by it connects, it will parse the common name (AWS::IoT::Certificate::CommonName) and create a thing using the common name & attach the certificate and a policy you specify to that thing.
I need to communicate between two desktop Java app, and the best way to do this is to use SSL (to prevent sniffers). I control both the client and server so self-signed is okay.
My question is if a certificate can be made and used from scratch programmatically (i.e. the end user does not have to physically do anything himself).
If this is possible, could you give me some pointers?
My question is if a certificate can be made and used from scratch
programmatically (i.e. the end user does not have to physically do
anything himself).
Before you think of generating certificates (programmatically or not), you need to decide how you're going to verify them. In the context of two desktop applications, the traditional way of verifying a server certificate might not be suitable.
The purpose of the certificates is to give a way to verify the identity of the remote party, so as to prevent Man-In-The-Middle attacks. The verifying party uses something it already trusts to make this verification; not doing so makes using certificates pointless.
In the traditional model (with a fixed server), the server certificate is part of a PKI and issued by a CA. The client verifies its authenticity against a set of CA certificates it trusts (typically using the rules described in RFC 5280, and it verifies the certificate is valid for the host name is was looking for (how this is done depends on the protocol, but best and historical practices are described in RFC 6125). Both steps are necessary to prevent MITM attacks. It's similar to verifying someone's identity using a passport: you want to check that the passport is real and from an authority you trust, and you want to check that the name (or picture) matches the name you're looking for (or the face in front of you).
When establishing a communication between two desktop applications, you're certainly going to have problems with both aspects: how to let the client verify the cert was issued by an entity you trust, and was issued to the entity you want to communicate with. If you generate the certificate programmatically no either side, it's certainly going to be self-signed, which will make verifying its authenticity from the other side difficult without another means of exchange (independent of this SSL/TLS communication). In addition, desktops tend not to have fixed host names, so a DNS-based (or even an IP address) identifier might be inadequate in this context.
You'll need to think of a way to publish the certificate in a way that the remote party can verify it trusts it, and to think of an identifying scheme to make sure the certificate belongs to the right entity (this is typically what goes in the Subject DN or Subject Alternative Name extension of the certificate).
Once you've made these decisions, you can use BouncyCastle's org.bouncycastle.x509.X509V3CertificateGenerator to generate your certificate (an X.509 v3 certificate should let you add extensions to the certificate, e.g. for key usage purpose, if you need them). There are various examples (for v1, v3 and/or self-signed, i.e. where Subject = Issuer) on the BouncyCastle wiki. I'd say that using this is the easy bit unfortunately (the administrative side of trust would be the hardest).
If both desktop applications are in fact both part of a more central application, you could run a service that issues this certificate, from a certificate request (CSR) generated within your application. A central server would effectively run your own CA, and your desktop applications would trust that CA. Depending on the complexity of your organisation, there are tools available to do this, or you could also use BouncyCastle to implement it, using the same classes (it would even be better if you implemented CRL/OSCP to be able to revoke certificates). In this case, you could make your application generate a CSR and submit it to your central CA. CSRs can be generated with BouncyCastle using PKCS10CertificationRequest. Again, how your CA verify the CSR comes from the right party, using external information, is also an administrative problem, perhaps you can tie it to an e-mail verification scheme or something like that.
Once you've generated your certificates, you'll be able to use Java's JSSE as your SSL/TLS stack (typically using SSLSocket). You may have to use custom X509TrustManagers to implement the certificate verification (depending on how you've designed your scheme to verify the certificate, if you're unable to use a traditional CA model). Just make sure you don't use trust managers that don't do anything in their check* methods; there are a number of examples of this around: you might as well not use certificates at all in this case, if you don't do anything to verify them (this would make the connections vulnerable to MITM attacks).
You could use a JCE based solution with SSLSocket, docs for jdk6 and its implementation: SSLSocketImpl.
Java SSL SSH:
You have Jsch lib to connect to any server with SSH protocol.
Java Toolbox for SSL:
You have Bouncy Castle.
Look at their resources and their documentation. The wiki provides some usefull examples with the latest releases:
ContentSigner sigGen = ...;
PublicKey publicKey = ....;
Date startDate = new Date(System.currentTimeMillis() - 24 * 60 * 60 * 1000);
Date endDate = new Date(System.currentTimeMillis() + 365 * 24 * 60 * 60 * 1000);
X509v1CertificateBuilder v1CertGen = new JcaX509v1CertificateBuilder(
new X500Principal("CN=Test"),
BigInteger.ONE,
startDate, endDate,
new X500Principal("CN=Test"),
publicKey);
X509CertificateHolder certHolder = v1CertGen.build(sigGen);
I'm new to SSL connections so here goes my question.
I have a desktop Java program in a JAR file. This JAR sends sensitive information over the internet to a remote Tomcat server. Of course I need to encrypt the data.
If I purchase an SSL cerfiticate say from Verisign, will the data sent over SSL be automatically encrypted?
I mean in my JAR, will I still need to do extra work like use Java encryption extensions API to manually encrypt my data over the SSL connection?
Thank you.
I mean in my JAR, will I still need to do extra work like use Java encryption extensions API to manually encrypt my data over the SSL connection?
Encryption will be done for you (with the Java Secure Socket Extension). Just establish your connection using https://. Maybe have a look at HTTP Client for a higher level API.
By the way, the certificate goes on the server side (unless you want to do client-authentication too in which case, well, you'll need a client certificate too).
And yes, you could use a self-signed certificate but one of the benefits of using a certificate signed by a well known Certificate Authority (CA) like Verisign, Thawte, etc is that you won't have to add it to the trust store of the client VM (unless you disable the verification mechanism).
Follow the SSL Configuration HOW-TO on how to setup https.
If your goal is just to get the encryptian, you don't need to buy a certificate. You can make your own. Buying a certificate just creates the verification chain back to verisign (or whomever) to give users a warm fuzzy that you're really who you say you are.
SSLSocket should handle most of the work for you.
All data sent over SSL is by definition encrypted, you do not need to worry about encryption at all. Also, you do not need to by a certificate to achieve that: you can issue one on your own.
If you'll set up the SSL on Tomcat and send your data over HTTPS then the encryption will be done for you. But you don't actually need to purchase a certificate if you only need encryption for your data channel, you could generate a self-signed certificate. Have a look at this page http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html on how to configure SSL for Tomcat. But note that HTTPS can be configured not to use encryption at all (at least on Apache httpd).
To answer your question, SSL implementations automatically encrypt the data. You don't need to worry about using additional encryption routines.
It might be easiest to purchase an SSL certificate because SSL implementations provide easy certification authentication using common root certificates and provide a verification service. However, you could save some money by using a self-signed certificate.
Even with a self-signed certificate, it's important to validate the signature on the server certificate from the desktop application when you connect to the server. This will prevent man in the middle attacks.
You won't have to add your self signed certificate to the store because you should be able to disable the automatic verification mechanism and use your own.
i have developed an application in java (J2ME),
and i want trusted domain for that application using goDaddy's certificate.
can i obtain it ?
let me re describe the full scenario.
i have developed an application.in which i want FILE IO operations to be done without the permission of user (for every read write, it means user will be asked only once.)
so to obtain that i want trusted domain for my application.
for that i need to sign my application using code sign certificate.
now go Daddy's certificate is not listed under Nokia 3110Classic, so i have externally added it in CA list.
but still its showing app signing option disabled.
so my question is can i obtain trusted domain using the goDaddy's code sign certificate ?
For an explanation about the MIDP security model, see answers to StackOverflow questions Application Error Occurs in Nokia 6300 and Privileged operations in netbeans mobility.
If the certificate you used to sign your MIDlet wasn't on the phone, just adding it to the phone may not be enough.
You probably need to add the goDaddy certificate to the MIDP runtime "trusted third party" security domain. Somehow. I'm not convinced that's possible on a Nokia 3110 Classic.
Godaddy certificates usually depend on a Starfield certificate. Make sure that is in place too.
Also, the app-signing might be off because you've only installed the public key.
Edit: Actually, the private key is not necessary on the box (nor desireable). I wonder if the box is missing the Starfield certificate.