Hello - New to letsencrypt.
Ubuntu 16.04 server/Postfix/Dovecot. We receive Paypal payments via an encrypted button. Paypal can authenticate using multiple certificates, but if the letsencrypt renewal wipes out the previous certificate with no overlap, we shall surely lose the ability to accept Paypal payments. The refusal is not exactly graceful either, just a ‘we are unable to decipher the certificate id’ or similar - not exactly confidence-inspiring for our customers.
The remedy is straightforward enough, but how can we avoid the interim loss of continuity?
Grateful for any lateral thinking.
Incidentally, we could not Paypal accept the certbot-created certificate - the virtualmin one works fine (not a question, so not worth a separate post). Thanks.
Could you substantially elaborate on this, such as showing what the exact error message is, and who generates it?
There should be absolutely no issue at all with continuity of service. One Let's Encrypt certificate is just as trustworthy as the next. PayPal shouldn't be "remembering" or "authenticating" to them, other than the certificate verification process that all TLS clients (such as your browser) perform.
Edit: Are you referring to Encrypted Web Payments ? I am not a user of this service but it doesn't seem to me like you should be using short duration Web PKI certificates (such as those from Let's Encrypt) for this ...
Thanks for your reply.
Yes, as I explained, we are using encrypted web payments.
I am attempting to pre-empt any problem (hence ‘we shall surely…’), there have been no errors generated yet, as we have not reached our first renewal.
My query was really aimed at other Paypal API users, whose opinions I would be interested to hear. For anybody not familiar with the routine:
We upload our certificate to the paypal control panel, who allocate it a Certificate ID. This ID is then incorporated into our web application and included in the code used to dynamically encrypt the payment information sent to Paypal whenever somebody chooses this method of payment.
At each SSL renewal, we have simply uploaded the new certificate to paypal, then updated our code to reflect the new ID, resulting in no loss of continuity. Paypal accept encrypted payment requests made using either of the IDs until we delete the expired one. This overcomes any problems with wierd over-aggressive browser cacheing causing any issues.
As far as the short life of the letsencrypt certificate is concerned, this is irrelevant - I should still be asking this same question if the certificate was good for 5 years…
I've given a couple of suggestions about this in your other thread at
This feature does not require a publicly trusted certificate from a CA. You can use a certificate you generate yourself.
A browser knows a certificate is authentic by because it is signed by a certificate authority like Let’s Encrypt. They won’t use a certificate signed by a key they don’t recognize. PayPal knows a certificate is authentic because you upload it after entering your username and password. They don’t care who signs it.
The biggest reason you would prefer not to use your main website’s certificate isn’t even the short expiry. It’s that typically the application code that generates PayPal links would not need to have permission to access your server’s private key. If the application code were to be compromised, it could compromise your server’s private key. Conversely, if your server’s private key we’re compromised, it would compromise the key used to generate links to PayPal.
It’s always a best practice to keep your keys used used for unrelated purposes separate. Also a configuration where code that can be executed from the internet (e.g. php) has been given access to your server SSL key would fail a lot of security scans.
That this allows you to set a more convenient expiry time for this use case and don’t need Let’s Encrypt at all for it is just a bonus!
That being said, what to do for key rotation is the same regardless of whether you use Let’s Encrypt certificates or ones you generate on your own:
- Generate a new certificate (or get one from Let’s Encrypt)
- Upload it to PayPal.
- Stop using the old certificate to generate links to PayPal and start using the new one.
- When you are confident that your customers would no longer use any PayPal links generated using the old certificate, you can delete the certificate in PayPal.
If your certificates are managed by certbot or a control panel, you’re probably switching step 2 and 3. That is, your website starts using the new certificate to generate links to PayPal immediately before you get a chance to upload it to PayPal.
The only way to avoid that while still using automated certificates for this purpose would be to identify if PayPal allows you to upload a new certificate programatically via an API, and then do that, either immediately when the certificate is obtained via e.g. a certbot deploy hook, or else in your application code the first time it generates a link to PayPal after the certificate gets changed.
Schoen - thanks, I shall read those next…
Patches - thanks for this considered reply.
I was aware of all you say, and am waiting from paypal for advice as to whether there is any way to update SSL via the API.
Nevertheless, you’ve probably already offered the solution, if what you say about paypal accepting any correctly-constructed certificate is correct. Having said that, we have been unable to get them to accept a Letsencrypt certificate created from the certbot cli, yet the Virtualmin module-created certificate is fine with Paypal. This is the subject of a discussion under the other thread to which schoen alluded above.
We shall produce a sensible expiry length OpenSSL certificate for Paypal-specific usage, which will suit our purpose perfectly.
I can only think that many years ago - when we were first learning paypal’s API - we found the dynamic encryption tricky and incorrectly attributed that to very precise certificate restrictions.
Many thanks for your help.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.