Our organization developed some application on java before 8 years and we have some customers who have installed our product in their environment and providing services.
In java 7 update 51, java has updated their security, so it is asking us to sign the jar files using public certificate.
Customer is not fine with ask every user to reduce the security level or add the site in exception list in control pannel java.
The question here is, do all the customer needs to buy one certificate for them self and sign the jars or as an organization we buy a certificate and the single certificate can be used for all the customers?
If you get a certificate for your organization, you can use it to sign any Java applications that you wish to deploy. A different certificate is not needed for each application or customer.
It's not even necessary to avtually "buy" a certificate. You could create a self-signed certificate using the java keytool and use it to sign your code. Then your customers would have to install that certificate into their java trusted certificate store and everything should be fine.
"Buying" a certificate is only necessary when you need every computer with a standard-trustlist to be able to run your application, but if you're in close contact with your customers - as it seems you are - you should be able to hand them a self-created certificate for installation on their machines.
Related
I'm writing a utility Mac OS X app that basically acts as a web server accepting incoming HTTP requests (think of it as a mock REST API server). I want to be able to support HTTPS, but ideally I'd like to remove the requirement for my users to have to purchase their own SSL certificates.
I've been thinking a little on how I might achieve this. Let's say I register a domain called myapp.com. I then purchase an SSL cert for myserver.myapp.com that is signed by a registered CA. I ship my app with those SSL cert details embedded within it. All my users have to do is update their /etc/hosts file to point myserver.myapp.com to whatever IP address my app is installed and running on.
In fact, by far, the most common scenario would be my app running on the same machine as the client, so I'm considering updating the main DNS entry for myserver.myapp.com to point to 127.0.0.1, and most users wouldn't have to change anything.
So, that's the basic theory. What have I missed that would make this an unworkable plan? A couple of things that have crossed my mind:
I could use a self-signed cert. However, many SSL clients barf (or throw up warnings) if the cert doesn't have a valid CA chain. I'm happy to pay the money for a real cert to alleviate this inconvenience for my users.
I would be embedding the private key for my SSL cert into my app. In theory, someone could extract that and use it to impersonate my app. I guess my reaction is "so what?" My app is a small productivity app, it isn't an e-commerce site. It doesn't collect sensitive info. It literally just simulates web server responses so devs can test their apps.
Any advice/feedback would be greatly appreciated. Thanks.
This won't work - but for nontechnical reasons.
Distributing an SSL certificate to your users along with its associated key will violate the issuance terms of your SSL certificate provider, and they will revoke the certificate when they discover what you have done. (This happened, for example, when Pivotal tried to offer SSL service for developers through sslip.io.) This will, of course, cause your application to stop working.
If your users have administrative access to their machines, they can create and trust their own self-signed CA using Keychain Access. Once they have done so, they could create a certificate (again, using Keychain Access) and insert that into your application to enable SSL.
As said in the other answer you can't ship the same certificate for everybody. What you could do is generate different for everybody:
The application ask them the domain name they want to use (a domain they must own, like myapp.example.com)
The application use the ACME protocol to get automatically a trusted certificate from let's encrypt
Note: you can provide them subdomains of a domain you control (like [clientid].yourappname.yourdomain.com) ONLY of you can register yourappname.yourdomain.com in the public suffix list (because let's encrypt have rate limits)
our customer using Websphere 7 decided to no longer use the self-signed certificates, but from now on always use some CA certificates.
I was browsing via the Security guide for Websphere environment and SSL settings, and just found this information:
A CA client must be created to connect to the CA server before
creating a CA certificate. You need to implement the
com.ibm.wsspi.ssl.WSPKIClient interface to enable WebSphere
Application Server security to communicate with a remote CA. The class
name needs be provided as part of the CA client when it is created
I am not sure if I understand it correctly. But for the situation, where I already have some CA certificate, and I just want to import it onto our environment, do I need to implement this interface?
Does that mean, that if I need to switch from self-signed certificates on Websphere to CA certificate, our software needs some implementation change?
I would expect only importing new truststores, keystores etc. but no java implementation.
Does someone have the knowledge about this change?
But for the situation, where I already have some CA certificate, and I just want to import it onto our environment, do I need to implement this interface?
No, you don't need to implement this interface, you can just import your certificates into your environment (to trust and key stores).
This interface is required if you would like to have automatic management with remote CA e.g. if certificate expires to allow WAS to automatically connect to CA and request for new one.
According to MSDN documentation, to send more than 500 push notifications per day, your service needs a certificate to establish an SSL tunnel to the WNS.
I see here http://msdn.microsoft.com/library/windows/apps/ff941099(v=vs.105).aspx how to upload the certificate, but how do I get the certificate? Do I need to install the certificate the my web server hosting my services? What if I am hosting my services in Windows Azure?
Firstly, this question is about MPNS (Microsoft Push Notification Service), not WNS (Windows Notification Service). They are two separate services, with WNS being now Microsoft's preferred platform.
Microsoft provides a list of MPNS-approved CA's (certificate authorities) here:
SSL root certificates for Windows Phone OS 7.1
The process for acquiring the certificate is roughly the same with all CA's. You need to create a CSR (certificate signing request) with your domain name as the certificate CN (common name), and send it to the CA. The CA charges a sum for certain validity period (typically 1, 2, or 3 years). Before the SSL certificate is issued, they normally do certain checks to ensure that you really own the domain name, e.g. by mailing the WHOIS owner of the domain and/or asking you to create a special DNS record.
Once you have your certificate, you need to install it as a client certificate in the server that makes the push notification calls to the MPNS servers. How do you do that, depends on your server architecture (.NET, Java, etc.).
http://www.verisign.co.uk/
you need a registered domain name and then you can register to buy a certificate, I think the cheapest I found for my app a few years ago was something like $99 but this may well be incorrect now.
Good Luck,
When i tried to call .Net web service http://....using windows 7 API's
Its working fine. But if i used with same web service https://... i got
security error like There is a problem with this website's security certificate.
Help me out for this query...
You're probably using a test certificate or other certificate not supported by the phone.
If that's the case then your question is a duplicate of Making a WP7 HttWebRequest POST with an untrusted cert?
The solution to your problem is that you can't and must get a certificate from a trusted root certificate authority.
The site you're accessing needs to have a valid certificate from an issuer recognised by the platform. The latest list of these issuers I've seen is here.
push notifications from authenticated services
Note Geotrust will give you a 30 day trial certificate which is handy for testing.
Update: New documentaiton of trusted certificate issuers.
Is it different from any other certificate I can generate via makecert or buy from some authority?
As mentioned by Mile L and Boot to the Head the Extended Key Usage is what determines the purpose that the key can be used for.
Most commercial certificate authorities (Verisign et al) issue certificates for single purposes, or for as few as possible.
They use this narrowing of the puropse to carve out different markets for the certificates and then price them accordingly.
You see them selling different Object Signing certs for Windows Assemblies / Java / Office / Adobe Air etc when (in most cases) the resulting certificate is the same.
For example the Comodo codesigning cert issued here can sign Java applets, WebStart applications, Firefox extensions and even Windows assemblies.
The certificate that's used to sign software is the same certificate that would be used to sign any document. What's different about signing software is where the signature finally resides. In a typical document signing, the signature just gets appended to the original document. You cannot append a signature to most types of software for obvious reasons (some interpreted languages would allow this, but I don't know if it's done in practice).
The solutions to the signature problem vary based on the execution environment. For an executable binary, the signature is often stored in a separate file. In Java you can have a signature embedded in an executable JAR file.
Microsoft has a good reference for an introduction to the signing process.
It depends on what you are doing with it. If you want the certificate to be accepted by a browser in an SSL communication, then it must have a root certificate installed in the browser. The certificates generated by authorities already have their root certs installed in browsers.
If you are using the cert just to sign an assembly, then you don't need it. It depends on who is checking the cert and whether they care if the root is a known authority.
More here:
http://en.wikipedia.org/wiki/Root_certificate
To my knowledge, certificates have a "key usage" attribute that describes what uses the cert is intended for: SSL server, code signing, e-mail signing, etc. So I think it's up to the OS, or web browser, or e-mail client, to check these bits.
When a cert is called into action, the role it purports to perform is as important as identification. It's not just about identity, but also about role authorization. An email protection cert should not be able to perform server authentication. Security concerns dictate a necessary restriction in the power given through a single certificate. The underlying API should enforce the correct usage, be it through the OS or an abstraction such as the .NET Framework.
There are different certificate types because there are very different roles in authentication and authorization that would need them. Allowing different certificate types and hierarchies allow for a model of certificate chains, as found in the "Certification Path" on a certificate. A Server Authentication cert will need to have a top-level CA cert somewhere in the trusted root certificates... or be a part of a family tree of certs which ultimately does. 3rd party Certificate Authorities, I'm sure, price them on a scale of functionality and trust.
Boot To The Head is right... there is an Enhanced Key Usage attribute which provides a description of what the cert claims the role to be (e.g. Server Authentication; or in the case of my CA's cert: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing). Look at the details in a certificate's properties and you'll find it.
I'd also add that a .NET assembly has to be strongly named (which requires it to be signed) in order to be added to the GAC.
There are different types of certs... from the CA that is bundled in Win 2003 server, you can request:
Client authentication
Email protection
Server authentication
Code signing
Time stamp signing
IPSec
Other