My application implements SSLPining with leaf certificate. And it's about to expire.
I researched and got the answer:
Some time before the certificate expires, release a new version of your app with a replacement cert in the pin list, as well as the original cert
How can i add both replacement cert and original cert to my project?
I just need to add a new certificate with any name and Will Alamofire go through all the certificate files I declare and if any match will it allow the connection?
Thanks
Yes, that will work. Alamofire's PinnedCertificatesTrustEvaluator gathers all certificates from the main bundle by default and checks to see whether the certificate received is within that set. So as long as both certificates are within that set, either of them should work.
Related
I am currently working with SSLSockets and I want to create an application that will be released to the public - for example an android app, iOS app or similar.
I have a domain which is secured by an SSL-certificate. Is it safe to generate a keystore from that certificate and insert it into the project-jar and pass it to the user? Is the keystore still valid when the ssl-certificate has to be updated?
You already got the point, if you create a trust store with the leaf certificate (the certificate used by the server) in it you have to update it every time the certificate is updated on the server (depending on the used CA every 3-12 months).
Therefore the common solution is to include the intermediate or root CA certificate as those certificates typically have validity time of up to 10 years or more. If you include intermediate or root CA certificate you don't have to update the app if just the server certificate is renewed by the same CA.
We are using IdentityServer4 and our version loads the signing key from a PFX file in file system or from the windows certificate store. Using the certificate works. The question is - which certificate issuer should be used in production?
Is a certificate from a public CA recommended? Or is it enough to have a self-signed certificate (without a CA at all) such as it can be created with IIS Manager?
In our tests we have found that the client could still validate the signature in the access token, even if the signing certificate would not have a valid CA chain on the client.
In the docs, it says that you can also use raw key material instead of a certificate:
http://docs.identityserver.io/en/latest/topics/crypto.html#token-signing-and-validation
In this scenario there would be no CA chain whatsoever.
That leads me to the assumption, that when the client loads the public signing key (via the HTTP(s) endpoint), the CA chain information might not be passed anyways. Is that right? Through the loading mechanism via HTTPs you also have a combined security mechanism.
So my conclusion is that for the signing credential a self-signed cert is just as safe as one from VeriSign. Can this be confirmed?
There is no certificate involved in signing and verifying the tokens. Only a private and public key (RSA or ECDSA key).
However a certificate can be useful to "import/transport" the keys into .NET. So, because of that we don't care about who issued the certificate.
When importing the key, one approach is to bundle the certificate that holds the public key + the private key and store it in a PKCE#12 file (.pfx/.p12 extension). Then load that file into .NET. Before .NET 5 working with keys was a bit hard.
The more important thing is that you can manage and deploy the private key in a secure way and that it is persisted over time.
Optionally, you can add support for key-rotation.
I am developing a desktop application. I can code sign it with .pfx file. I will get that from CA. But what if I want to install it in a different system. Will it reflect there as well? Because I can't share my .pfx file with everyone.
You should not share the *pfx as it contains the private key.
The trust to the signature comes from the trust chain - so when the issuing CA and all intermediate CAs up to the root CA are in the trust store (Windows Trust Store, MAC Key Chain or cacerts.pem for OpenSSL/Java) the signature is trusted as long as
the certificate is not revoked
the signature certificate is not expired or the signature contains a counter signature (RFC3161 timestamp).
I'm using the SignedXml.CheckSignature(X509Certificate2, boolean) method. I would like to know what checks are performed when deciding the validity of the certificate. I have verified that the Current User/Not Trusted list is checked. The documentation says it will use the "address book" store, searching by subject key identifier, to build the certificate chain. I imagine this means the Local Machine and Current User certificate stores?
Am I right to think that certificate revocation and signature timestamp are not checked? To do an OCSP check for certificate revocation, am I obliged to use Bouncy Castle?
In the remarks in the msdn article you link to one finds:
In version 1.1 of the .NET Framework, the X.509 certificate is not verified.
In version 2.0 and later, the X.509 certificate is verified.
In version 2.0 and later of the .NET Framework, the CheckSignature method will search the "AddressBook" store for certificates suitable for the verification. For example, if the certificate is referenced by a Subject Key Identifier (SKI), the CheckSignature method will select certificates with this SKI and try them one after another until it can verify the certificate.
Thus, first of all the behavior of that method has changed in different .NET framework versions. So for reproducible results, you had better not count on that method even check the certificate at all.
Furthermore, the formulation try them one after another until it can verify the certificate sounds like there just might be the mathematical test whether or not the certificate is signed by its alleged issuer.
https://referencesource.microsoft.com/#System.Security/system/security/cryptography/xml/signedxml.cs,b9518cc2212419a2
It checks
The certificate has no Key Usage extension, or the Key Usage extension has either Digital Signature or Non Repudiation usages enabled
The certificate chains up to a trusted root authority
The certificate has not been revoked
The certificate was not expired when you called this method
It doesn't know when the document was signed, so it doesn't answer that question.
That none of the certificates in the chain are explicitly prohibited by the user or system configuration.
I am trying to create certificates that will allow me to send push notifications on my device and I am total lost. I have used certificates for BETA and distribution but adding push notification is pain.
When I do create certificates for BETA testing, I do the following steps.
From keychain, Request a certificate from a certificate authority.
In Apple Provisioning Portal under Certificates, create a certificate uploading file keychain file.
Assume APP ID is created perfectly and devices are ready.
In Apple Provisioning Portal under Provisioning, I create a new profile and download mobile provisioning file to add to the XCode organizer.
That above steps works and I can BETA test. Now in order to enable push notification, I have setup server which is tested with push notification and is 100% working. When I configure for push notification, I need to upload keychain file. Is that the same file I uploaded under Certificates? There is a file in return which I double click and it gets added to the keychain, am I doing it right?
If I understand your question correctly, the answer is no, it should not be the same file. I'll explain the entire process in detail and hopefully that will clarify the situation (and what you need to do next).
When you enable push notifications, you need to do four things:
Create a private/public key pair.
Create a certificate signing request (CSR), signed with your private key.
Submit the CSR to Apple and download a signed certificate.
Create a file containing your certificate and private key, for validating each APN request.
Some points:
I recommend you use different keys for development (sandbox) and production APN. You can re-use the keys if you are sending notifications to different apps, but it is safer if you don't re-use keys between development and production.
The file you "submit" to the provisioning portal is the certificate request. You will have one CSR file for each certificate. You will create a two CSR for each app (bundleID); one for development, one for production. The CSR created with your development key should be submitted for development and the CSR created with your production key should be submitted for production.
Note: Keep the CSR files. You don't have to have them, but it will save you some time when you need to re-send the certificate requests.
After submitting your CSRs, you will be able to download the actual certificates. They aren't ready immediately, so give Apple a minute or so and then refresh your browser. The difference between the CSR and a certificate is important: the certificate is signed by Apple; it validates your ability to send push notifications. Download the certificates and load them into your keychain (double clicking is fine).
Note: the certificate is useless without your private key; so you will need to safely export your private key if you switch computers.
Any computer sending an APN request will need both the private key and the certificate. You can export them as a single .p12 file using Keychain Access. (I name mine MyAppCertKey.p12 to indicate that the file contains both the certificate and the key.)
Last, I wrote up a detailed explanation on testing / verifying communication with Apple's servers (from the terminal). It's a little complicated since you need to have some root certificates set up for openssl to validate against; however, it will tell you if you are communicating correctly with the servers, without requiring any work on the receiving app itself.
Couldn't able to connect to APNS Sandbox server
Hope that helps.