I don't have any experience on using a digital cert.
Recently I wrote an application in J2ME and Qt for the Nokia S40 and S60 /Symbian ^3/Anna/Belle series phones.
My question is mainly on S40 J2ME phones.
My app need to read /write from memory cards and thus needs a digital cert signing.
I plan to let users download my apps from my site and my questions are:
If I bought a cert, does it mean that I use the same cert to sign any number of J2ME apps? Or one cert one app?
After signing an app with a cert, will it run after the cert expired? Suppose the cert is valid at the time signing the code. I read some articles about timestamp for PDF documents and Microsoft code signing, and not sure whether it is needed for J2ME apps.
I assume many S40 users won't connect to internet. But when a user tries to install the MIDlet, is it necessary to connect through network to the cert issuer's site to verify the cert?
You can use the purchased certificate to sign any number of applications until it expires
Your midlet will still work and install but you will not be able to sign new ones with an expired certificate. See also this post
certificate validation does not require network access. The root certificate of the issuer is already on the device. Be aware that you should use a certificate issuer whose root certificate is on your target devices.
Related
I am having problems correctly installing the OAuth certificate required for Xero partner integration on IIS 7.5 on Windows Server 2008 R2. There used to be guidance from Xero on this at http://developer.xero.com/documentation/advanced-docs/using-partner-applications-with-iis/ but the page just 404s now.
I've installed the certificate to the Trusted Root Certifications Store as per the prior Xero advice, and my code can retrieve the certificate (using its serial number); but when I try to access the private key, I get a CryptographicException: Keyset does not exist error, which other SO posts suggest is a permissions error (my application runs under a dedicated service account), but all those posts assume the certificate is installed in the personal certificate store - the TRC store does not give me the option of granting permissions to the service accounts or any other account.
I think that page used to give information about installing an Entrust client certificate as partner applications in the past needed to use one.
You don't need to use a client certificate these days and partners should instead direct their traffic to "https://api.xero.com" instead of "https://api-partner.network.xero.com".
You also don't need to install your oAuth certificate as that certificate is used only for signing your requests.
I currently develop a small system consisting of an embedded server (including a small display) and some mobile devices (at the moment just Android phones).
These mobile devices should be able to talk to the embedded server over a secure channel. For this purpose, the server generates a self-signed SSL certificate during the very first boot process.
If a new mobile device should be connected to the server, the server displays a QR code consisting of:
Server IP
SSL certificate fingerprint
Random device ID
The user scans this QR code using his mobile device. The mobile device connects to the server and checks whether the SSL certificate fingerprint matches the one scanned before.
Is this considered secure? If not, how would you solve this problem?
An alternative approach:
On the very-first boot, the server generates a certificate request and sends it to a central CA server which signs the certificate. The client devices has installed the CA certficate and verifies the server certificate against it.
However, everyone could send a certificate request to the CA server and would get a signed certificate. (One could propably implement some authentication for the CA server using a "master key" but once that is extracted from a system image, the whole authentication becomes useless). In addition this setup requires a central server which I like to avoid since the product may be used in a "offline" environment.
Yes, this is considered secure because the fingerprint of the server's certificate is transferred to the client via a trusted mechanism (being physically next to the server to receive the fingerprint via a difficult to tamper with transport mechanism). If a MITM attack were to be attempted after the initial setup, even though server name would be the same, different keys would have been generated so the fingerprint would be different and the client would detect this and can appropriately reject the communication.
It could also be argued that this method is more secure because the client does not need to trust a 3rd party to verify the authenticity of the certificate. CAs do occasionally issue fraudulent certificates.
We have a backend server that services a multi-platform app that will be launched on iOS, Windows 8, Windows Phone 8 and Android. We'd like to use in production as few certificates as possible (preferably just one) to attain the following purposes:
secure communication (HTTPS) with the client application
authentication to the Windows Phone Push Notifications Service
authentication to the Apple Push Notifications Service
Besides taking care that the certificate is issued by a common trusted root authority, are there any other impediments that could prevent a single certificate from being used simultaneously for all these? Is it a viable possibility or is it instead necessary to resort to one certificate for each of the above purposes?
Gabriel I guess there is a problem. Main one is that HTTPS certificate private key cannot be coded by a secret this kind of certificate contain *.crt and *.key file which are not secured. When You want authenticate yourself or server in some Service for example Windows phone push like you have listed there is need to create hash for your private key with secret aka pin or password. What make You use at least two different certificates.
Second thing is that purpose of using certificates is to validate the issuer and to authenticate user/service provider. HTTPS ssl certificate issued by a trusted CA show to the user Hey this is trusted website You should not be afraid passing sensitive data through the service, and the certificates which are used to authenticate are just saying Hey its me I am authorized to use this application Purpose of those certificates and different so certificates them self should be different. Using the same cert for actions like You have listed cause necessaries vulnerabilities and is highly NOT RECOMMENDED
I an responsible for deploying a large amount of embedded devices and want to add https.
I've done a bit of googling and am a little confused as to where exactly my plan falls through.
Get a certificate signed by a reputable CA
Use the corresponding private key to sign new certs for each device
User connects to device (e.g.192.168.1.40) and receives 2 certificates
User's browser verifies that the device's cert. was issued by my company
User's browser verifies that my companies cert. was issued by reputable CA
Can someone please poke a few holes in that??
Similar question here
In J2ME when you sign a JAR with a certificate chain that includes an intermediate certificate (such as one from obtained from Verisign), does the device need to have the intermediate certificate installed as well as the root certificate during verification?
I am guessing the answer is no because the intermediate certificates are stored in the JAD file in the MIDlet-n-m properties where m is 2 or greater, and I believe the device references these while verifying. If that is true then J2ME certificates are different from SSL website certificates which require the intermediate certificates be installed in the browser, correct?
Finally if this is all true then couldn't anyone who gets a certificate from Verisign or any other CA with their root certificate on the device just go ahead and sign their friend's certificates and then their friends will be trusted?
Seems like a flaw in the system if this is all true...
The certificate one gets from verisign would typically be trusted to sign a MIDlet but not another certificate. Certificates trusted to sign MIDlets usually are not trusted to sign native applications either.
Between this and the (admitedly advanced and not always available) ability to revoke certificates, the system is fairly safe as long as trust is preceded by due diligence (so your Mobile Network Operator doesn't start trusting trojans and such...)
Frankly, it's not like mobile airwaves are inherently secure anyway.