I have integrated paypal express checkout with my app. Few days back I got following email from Paypal.
Dear Customer,
In keeping with industry standards set by the Certification Authority/Browser (CA/B) Forum, PayPal will discontinue supporting 1024-bit key length certificates and will migrate to 2048-bit certificates before the end of 2013.
We have completed the installation of 2048-bit certificates for all API endpoints in our PayPal Sandbox and Payflow Pilot environments, and we will be doing the same for our production environments starting on August 6, 2013.
We strongly encourage merchants to thoroughly test any existing integration(s) in the PayPal Sandbox and/or Payflow Pilot environments to ensure this migration will not cause any unforeseen issues.
Please have the team or person responsible for your integration refer to the following:
If you need to import the new PayPal Sandbox and/or Payflow Pilot server certificates to your application or system truststore, you can download production and Sandbox certificates from https://ppmts.custhelp.com/app/answers/detail/a_id/952.
If you don’t typically import the server certificates to your truststore, you can proceed with testing with no other action required.
If you have any questions, please contact PayPal Merchant Technical Services by filing a ticket; refer to PP-LIVE-3503. You may also visit our Live Site Status blog.
Sincerely,
PayPal
I am using API signatures instead of certificates. So, I really dont need to do anything here, right?
It's not the API certificate that is changing, it's the endpoint certificate that's changing to 2048. So whether your API credentials consist of either a API Signature or an API Certificate shouldn't matter.
You will only need to change anything if you're somehow storing and validating PayPal's API endpoint SSL certificate against a locally stored copy of the (same) SSL certificate. Often this is done in a so called 'truststore'.
Since PayPal's API endpoint certificate will change, you would need to update the certificate in the truststore accordingly.
So yes, you won't need to change anything if you're merely using an API signature or API certificate for API authentication.
Related
I would like to use google certificate transparency API to check the malicious SSL certificates(if any) of my domain. I am able to get all the certificates but how do i check whether the certificate is legitimate or not.
I had found this repository(https://github.com/ProtonMail/ct-monitor) but this simply searches certificates and stores it . What is the use of storing these certificates unless we validate the certificates first.
Can any one suggest me how do i get to know the malicious SSL certificates using this google certificate transparency api.
Certificate Transparency logs are, as explained on the CT site:
simple network services that maintain cryptographically assured,
publicly auditable, append-only records of certificates. Anyone can
submit certificates to a log, although certificate authorities will
likely be the foremost submitters.
The logging of the certificates in this fashion allows for interested parties (e.g. domain owners) to monitor these logs for malicious/erroneous
entries.
But a certificate being logged in a CT log doesn't mean it isn't a bad certificate. As explained on the CT site:
Certificate Transparency relies on existing mitigation mechanisms to
address harmful certificates and CAs--for example, certificate
revocation--the shortened detection time will speed up the overall
mitigation process when harmful certificates or CAs are discovered.
So CT API won't help you in working out whether a certificate is malicious - you need to check using other methods such as checking of certificate revocation lists (CRLs) or by using the Online Certificate Status Protocol (OCSP). See this related question on how to check certs. There are sites that allow for checking of certificates e.g. revocationcheck.com. Modern browsers seem to be converging on the use of compressed lists of CRLs - Mozilla's now using CRLite, whilst Chrome uses CRLSets.
The CT API allows you verify that a certificate has been logged in the CT logs which means that domain owners can monitor them and promptly insert any malicious/erroneous certificates into the relevant CRLs so they won't be used any longer.
I am setting up a webhook URL for Uber API integration. It is mandatory to use 'https'. For testing i am using a self-signed certificate but the callbacks from uber server are not hitting my endpoint. Do i need to get a real certificate just for testing?
We require a valid ssl certificate in order to receive a webhook. The great news is you can easily setup an ssl certificate for free with letsenrypt. Find out more at https://letsencrypt.org/getting-started/.
Get started at https://certbot.eff.org/
As per the paypal security upgrade on Jan 17th 2016 they are saying that the server needs to be installed with a ssl server with ssl of algorithm SHA-256 and the certificate needs to verify with a G5 ROOT certificate. But my doubt here previusly i can test the paypal sandbox payment in my localhost(a server without https) and it was worked perfectly. But as per the new upgrade from the paypal team is there any option to check the api service in sandbox in a http server(may be on localhost). When i try this i got a handshake_failure exception.
This was my mistake and finally i understood that ssl not needed. When i have update the paypal sdk jar to 1.4 the issue cleared.
I am not sure it is neccessary if I am using PayPal express checkout for recurring payment, do I need https/ssl for my website to connect to PayPal? I am using Ruby on Rails and there is a gem called "paypal-express". It is working well without ssl in sandbox environment. Any suggestion? Thank you.
If by 'https/ssl' you mean whether your site itself needs to support SSL traffic over HTTP (and thus have a valid SSL certificate): no, it doesn't.
You do however need to be able to establish an SSL connection. Specifically, to PayPal's API endpoint.
This means you need to allow outbound SSL traffic via your firewall (if you have any) and your environment needs to support this.
Ensure you have a valid copy of the root certs (I usually suggest http://curl.haxx.se/ca/cacert.pem) to valid the SSL certificates against.
Callbacks required SSL as stated here: https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECInstantUpdateAPI/
I am Authenticating all my users through a Microsoft product using SAML 2.0 with a X509 Certificate. The certificate is close to expiration, and I am not sure if after the certificate expires, my Service Providers will continue accepting my tokens.
I am very VERY new to SAML and SSO in general, so my apologies for not using the right terms.
If your Service Providers are compliant to the specification they will stop processing your SAML messages (Responses) once your signing certificate expires.
Unfortunately, there is no easy way to tell ahead of time. You will probably need to contact each one to find out how they handle this situation -- homegrown solutions may be more lenient than commercial products in this regard and allow SSO transactions to continue.