I'm working on a mobile APP, and SSL Pinning included.
Can anyone tell me the difference between credential and certificate in SSL challenge?
What's the difference between certificate chain and certificate?
Do I have to compare all the certificate?
credential is anything that validates. like RSA key, password, API-keys,
and SSL so in this process a SSL based authentication is done for identification between two parties which will use a SSL certificate
Related
I'm reading this article on iOS push certificates, and I'm confused about this paragraph:
Your backend sends notifications through Apple's servers to your application. To ensure that unwanted parties are not sending notifications to your application, Apple needs to know that only your servers can connect with theirs. Apple therefore requires you to create an SSL certificate to be able to send push notifications.
My understanding of SSL certificates is that if a server has one, that server is able to encrypt data that it sends to a device. But it says here Apple needs to know that only your servers can connect with theirs. I don't understand how having an SSL certificate ensures that. Does anyone have any insight?
The article shouldn't have used the term SSL Certificate. SSL is the Secure Sockets Layer (which was superseded by TLS many years ago). SSL and TLS define the handshake that is used to negotiate encryption on a connection.
Enabling SSL on a web server required you to have a certificate to verify your server's identity and so this became known colloquially as an "SSL certificate".
While it isn't often used on the web, in SSL/TLS both parties can present a certificate so that there is mutual authentication.
What you typically have is actually an x.509 certificate. This is the case with the push notification service.
An x.509 certificate contains some information including the identity of the certificate holder, their private key and a signature from a trusted party that can be used to verify the information.
For push notifications, the developer generates a certificate request and submits this to Apple who sign it with their private key. Apple is the trusted party in this case.
When this certificate is subsequently presented to Apple's server they can verify that signature using their public key to confirm the identity of the connecting party.
You have has encrypted the message with their private key (Apple can decrypt it with the public key included in the certificate).
What this means is, that as long as the developer has kept their private key secure (which is why you wouldn't connect directly to the push service from your app, for example) then Apple can be sure of the identity of the server making the connection.
If someone was trying to impersonate your server then, as long as you have kept your private key secure, they can't encrypt the data properly. If they use a forged certificate that uses a public/private key pair known to them then the signature on the certificate won't be valid and Apple will reject it.
Openstack Keystone PKI uses two certificates as this document mentions:
https://www.mirantis.com/blog/understanding-openstack-authentication-keystone-pki/
CA certificate and the signing certificate.
My understanding so far: Signing key is used to sign the user token while the signing certificate contains the corresponding public key and will be shared with the service endpoint to be used while decrypting the user token.
Is this correct? If so, what is the purpose of the CA certificate and the CA key?
I'd suggest the OpenStack documentation at http://docs.openstack.org/admin-guide-cloud/content/certificates-for-pki.html
PKI stands for Public Key Infrastructure. Tokens are documents, cryptographically signed using the X509 standard. In order to work correctly token generation requires a public/private key pair. The public key must be signed in an X509 certificate, and the certificate used to sign it must be available as a Certificate Authority (CA) certificate.
Tokens are both signed and verified. There's no decryption.
The certificate and certificate authority used can be internal or external and how the cloud provider choses to configure it is up to them.
In PKI environment certificate(signing cert) is signed by CA. CA is usually external entity but if you use keystone-manage pki_setup to generate the signing keys it first setup the CA locally and sign the certificate which keystone uses.
CA key is used for CA, keystone do not have any use of it.
Keystone just need own private key, Signed Certificate and CA certificate.
Hope this is useful.
-Thanks
I understand the use and necessity of SSL Certificates. I am looking for a detailed explanation of the relationship between http protocol and SSL Certificate and also between https and SSL Certificate.
In AFNetworking defining _AFNETWORKING_ALLOW_INVALID_SSL_CERTIFICATES_ allows invalid certificates.
Assuming this flag is not set, the library should deny invalid certificates by default. But what if the server has no certificate installed at its end? I see that I can access a server with no certificate using http protocol.
And does the default certificate validation occur for https protocol only?
I want to access only those servers with a certificate and which are valid over http and https? Is this feature required and if so is it possible?
I think you don't understand what HTTP and HTTPS are about:
http is the session protocol to communicate with servers without encryption. Everything is sent in the clear and there is also no way to verify the authenticity of the server (i.e. that the server responding is indeed having the correct hostname). A server doesn't need an SSL certificate in this case.
https is used when you want to ensure that communication with the server is encrypted. For this, the server needs an SSL certificate and before anything is sent over the HTTP session, a handshake will take place allowing the client to fetch the SSL certificate of the server in order to encrypt the data that is sent. So an SSL certificate is only used for HTTPS connections.
It is also possible to verify the authenticity of the server, depending on the SSL certificate used. All browsers (and by default on iOS, unless you explicitely change this in your app) will only accept SSL certificates that have been issued by known certification authorities. This way you can be sure that the server is indeed located at the hostname you requested. Depending on the SSL certificate the owner of the server might also be verified (i.e. that the server indeed belongs to the company it claims to belong to).
You hear a lot about how you can use SSL pinning to increase the security in your app. I was always under the assumption that SSL pinning is only helpful if you use a self-signed cert. Are there benefits of SSL pinning when using a cert signed by a cert authority, or does the CA make that unnecessary?
SSL/TLS has some issues, and the root of those issues is the CA system. By default, your browser trusts a bunch of CAs. Other than a few basic checks such as hostname, etc, the real power of the SSL comes from the verification of the certificate via the intermediaries until you get to a certificate that you trust.
Certificate pinning specifies that you will only trust a given certificate for a given web site. That is to say, if you received a "valid" certificate signed by a different CA (even if you trusted that CA) you would not trust it for this site.
In short, the fact that the CA has signed a cert does not reduce the need for certificate pinning.
For example: Companies sometimes intercept SSL. To do this, they actually serve the client a different SSL certificate that is valid for the host that the client is trying to access. Because they can insert any certificate into the trusted root (windows via GPO) they can insert their certificate instead of the actual one issued by the host. In this scenario, the SSL interception is transparent to the user. They are still being issued a "valid" certificate that is signed by a CA they trust (whether they know it or not). If you had been using certificate pinning, the new cert would be rejected.
There are cons to certificate pinning, mostly around the management of the cert as it expires etc.
See this link for more info.
The Application i am working on needs to connect to a webservice over https, The certificate is trusted and valid.
I have used NSURLConnection is previous projects to use soap over http
Can anybody please point the difference between the two above mentioned scenarios,
I also need to understand what exactly happens when connecting over https, is the certificate stored automatically on the device, how does ssl handshake happen.
Any Pointers in this direction will be really helpful.
Regards,
Ishan
I need some clarification. Is the certificate signed by Apple for use with notifications or is it signed by an SSL root certificate authority (like VeriSign)?
Apple signed certificates are only to be used with WebServer to Apple Server communications like the Apple Push Notification Service. They are not intended for iOS device to WebServer.
A SSL certificate signed by a SSL root certificate authority should just work.
I think you are looking for an HTTP over SSL/TLS primer. So, here it goes.
HTTP is an unencrypted channel. The request and response are in a plain text data stream. HTTPS is an encrypted channel. The request and response are in a data stream encrypted using a shared master key. The magic of SSL/TLS is how this encrypted channel is created.
First, the client and server say hello to each other (in a clear channel).
Next, the client downloads the server's public certificate (in a clear channel).
At this point, the client has some work to do. It needs to verify the certificate. It needs to know that it understands the certificate, that the date range is valid, that the certificate is signed by a trusted certificate authority, and that the certificate has not been revoked.
Now, the client knows that it can trust the server.
Next, It sends a few short messages encrypted with the public key of the server (which is in the server's public certificate). These messages can only be decrypted by the server's private key (which only the server knows about). These messages allow the client and the server to negotiate a master key.
Finally, the client and the server begin the normal HTTP request and response using the newly created encrypted channel.
I hope this is what you are looking for. For a more detailed description see: http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
If the certificate was issued by a chain of certificate authorities whose root is trusted by Apple, then there is nothing to do. The iOS device will accept the certificate, as long as it is otherwise valid (ie not expired, not revoked, etc).
If the CA chain's root is not trusted by Apple, you will need to download the root's certificate to the phone. This can be done (I think) via the iPhone Configuration Utility. Enterprise provisioning scenarios undoubtedly support this also.