I have a java app that needs to be able to communicate with a web server over ssl using an client x509 certificate (for encryption negotiation) - the private key is in the java keystore to which access is protected by a passphrase.

Now the best part: I don't want to store passphrase in app, instead I want to send this passphrase via secure connection from server ... vicious circle.

What possibilities do I have? It looks like both sides need their own keypairs or symmetric key for encryption, or I need to send a passphrase via unsecured connection which anyone can sniff ;/

What platform is this app on? Android? Windows? – Mike Ounsworth

Android

P.S. I can deploy the cert after first installation and set keystore passphrase to user encrypted password for double protection, this way the client can ensure that the cert was not tampered with during app usage.

Usually I don't ask questions like this, but why do you want to encrypt the keystore with a server-provided password? What is the problem you are trying to solve by doing that? – Mike Ounsworth

insurance for client that server is the right one

"insurance for client that server is the right one" -- I don't understand, that's the whole point of ssl server certificates. The SSL handshake already proves the identity of the server. – Mike Ounsworth

only then when the certificate is trusted - thats the whole point

how my app can check if it can trust given cert  ?

Checks whether the specified certificate chain (partial or complete) can be validated and is trusted for server authentication for the specified key exchange algorithm.

If your server's certificate is from a public CA, then the root should already be in Android. If it was issued off a private CA, then you should be adding your root cert to the Java Keystore during install.

Authority certificate is cross-signed by IdenTrust ("DST Root CA X3" Root CA)

case:

• cert is in app
• app is deployed on device
• server is showing cert to app on negotiation
• app is comparing cert (validating by it's copy)
• in moment when app is reading cert [ FROM FILE ] client need to be sure that cert was not tamped (lets assume that we do spoofing cert on server and on client site simultaneously to enforce data exchange in app  )

This is safe because the app .apk is code signed, so the cert can not be modified.

#SORRY?

• nova days even EPROMS are writable ???? if you can write into memory there is no such thing like immutability :)
• besides rooted device is vulnerable for fs files altering

can u some how guarantee that more or less that cert on both sides can't be spoofed ? without user knowledge ?

certs == entrust == knowledge

public key infrastructure is good when u exchange with keys eye on eye but I want to be sure that user gets what it should / and user should not worry that he could get not what he should :) in the chain:

END USER <------ INTERMEDIARIES -------> PUBLISHER

• in publish process
• in using process

I have a java app on Android that needs to be able to communicate with a web server over ssl using an client x509 certificate (for encryption negotiation) - the private key is in the java keystore to which access is protected by a passphrase.

Now the best part: I don't want to store passphrase in app, instead I want to send this passphrase via secure connection from server ... vicious circle.

What possibilities do I have? It looks like both sides need their own keypairs or symmetric key for encryption, or I need to send a passphrase via unsecured connection which anyone can sniff ;/

I can deploy the cert after first installation and set keystore passphrase to user encrypted password for double protection, this way the client can ensure that the cert was not tampered with during app usage.

how can my app check if it can trust given cert?

The Authority certificate is cross-signed by IdenTrust ("DST Root CA X3" Root CA)

case:

• cert is in app
• app is deployed on device
• server is showing cert to app on negotiation
• app is comparing cert (validating by it's copy)
• in moment when app is reading cert from file the client need to be sure that cert was not tampered (lets assume that we do spoofing cert on server and on client site simultaneously to enforce data exchange in app)

I have a java app that needs to be able to communicate with a web server over ssl using an client x509 certificate (for encryption negotiation) - the private key is in the java keystore to which access is protected by a passphrase.

Now the best part: I don't want to store passphrase in app, instead I want to send this passphrase via secure connection from server ... vicious circle.

What possibilities do I have? It looks like both sides need their own keypairs or symmetric key for encryption, or I need to send a passphrase via unsecured connection which anyone can sniff ;/

What platform is this app on? Android? Windows? – Mike Ounsworth

Android

P.S. I can deploy the cert after first installation and set keystore passphrase to user encrypted password for double protection, this way the client can ensure that the cert was not tampered with during app usage.

Usually I don't ask questions like this, but why do you want to encrypt the keystore with a server-provided password? What is the problem you are trying to solve by doing that? – Mike Ounsworth

insurance for client that server is the right one

"insurance for client that server is the right one" -- I don't understand, that's the whole point of ssl server certificates. The SSL handshake already proves the identity of the server. – Mike Ounsworth

only then when the certificate is trusted - thats the whole point

how my app can check if it can trust given cert ?

Checks whether the specified certificate chain (partial or complete) can be validated and is trusted for server authentication for the specified key exchange algorithm.

If your server's certificate is from a public CA, then the root should already be in Android. If it was issued off a private CA, then you should be adding your root cert to the Java Keystore during install.

Authority certificate is cross-signed by IdenTrust ("DST Root CA X3" Root CA)

case:

• cert is in app
• app is deployed on device
• server is showing cert to app on negotiation
• app is comparing cert (validating by it's copy)
• in moment when app is reading cert [ FROM FILE ] client need to be sure that cert was not tamped (lets assume that we do spoofing cert on server and on client site simultaneously to enforce data exchange in app )

This is safe because the app .apk is code signed, so the cert can not be modified.

#SORRY?

• nova days even EPROMS are writable ???? if you can write into memory there is no such thing like immutability :)
• besides rooted device is vulnerable for fs files altering

can u some how guarantee that more or less that cert on both sides can't be spoofed ? without user knowledge ?

certs == entrust == knowledge

public key infrastructure is good when u exchange with keys eye on eye but I want to be sure that user gets what it should / and user should not worry that he could get not what he should :)

I have a java app that needs to be able to communicate with a web server over ssl using an client x509 certificate (for encryption negotiation) - the private key is in the java keystore to which access is protected by a passphrase.

Now the best part: I don't want to store passphrase in app, instead I want to send this passphrase via secure connection from server ... vicious circle.

What possibilities do I have? It looks like both sides need their own keypairs or symmetric key for encryption, or I need to send a passphrase via unsecured connection which anyone can sniff ;/

What platform is this app on? Android? Windows? – Mike Ounsworth

Android

P.S. I can deploy the cert after first installation and set keystore passphrase to user encrypted password for double protection, this way the client can ensure that the cert was not tampered with during app usage.

Usually I don't ask questions like this, but why do you want to encrypt the keystore with a server-provided password? What is the problem you are trying to solve by doing that? – Mike Ounsworth

insurance for client that server is the right one

"insurance for client that server is the right one" -- I don't understand, that's the whole point of ssl server certificates. The SSL handshake already proves the identity of the server. – Mike Ounsworth

only then when the certificate is trusted - thats the whole point

how my app can check if it can trust given cert ?

Checks whether the specified certificate chain (partial or complete) can be validated and is trusted for server authentication for the specified key exchange algorithm.

If your server's certificate is from a public CA, then the root should already be in Android. If it was issued off a private CA, then you should be adding your root cert to the Java Keystore during install.

Authority certificate is cross-signed by IdenTrust ("DST Root CA X3" Root CA)

case:

• cert is in app
• app is deployed on device
• server is showing cert to app on negotiation
• app is comparing cert (validating by it's copy)
• in moment when app is reading cert [ FROM FILE ] client need to be sure that cert was not tamped (lets assume that we do spoofing cert on server and on client site simultaneously to enforce data exchange in app )

This is safe because the app .apk is code signed, so the cert can not be modified.

#SORRY?

• nova days even EPROMS are writable ???? if you can write into memory there is no such thing like immutability :)
• besides rooted device is vulnerable for fs files altering

can u some how guarantee that more or less that cert on both sides can't be spoofed ? without user knowledge ?

certs == entrust == knowledge

public key infrastructure is good when u exchange with keys eye on eye but I want to be sure that user gets what it should / and user should not worry that he could get not what he should :) in the chain:

END USER <------ INTERMEDIARIES -------> PUBLISHER

• in publish process
• in using process