Hi,   Will the intermediate certificate be included in the certificate chain from the production servers or not? Zuora best-practices (stated on the other thread) explicitly say that a server will send the entire cert chain, but as I already pointed out on that post, the PT1 servers do not do this.   Will the production servers do it or not? This matters, because it changes what we need to put in our keystores. I have had this question open and unanswered on the other thread since October 12. It's now nearly 2 months later, will it be possible to get an answer now that we're about to change production?   Thanks,   Ben ... View more

I believe that a keystore which now works for connecting to the sandbox environment should also work for the production environment, if I understand anything about what has happened with these upgrades.   Someone from Zuora please correct me if that's wrong, however! ... View more

Hi,   I also feel it necessary to point out that Zuora Moderator Viktor states above that "A properly configured server will provide all certificates necessary to verify it’s server certificate, minus the root, during the TLS handshake." and provides a tool for us to make this check against servers.   This is the result using that tool for "rest.pt1.zuora.com":     You will notice that it says "This server's certificate chain is incomplete."   We actually had an outage on our UAT system when the certificate upgrade went in because we expected the full chain to be presented as Viktor asserted above and so configured our keystore with the root certificate, expecting that to suffice. Currently the Zuora PT1 environment does not adhere to the Zuora-recommended standard.   Is this something Zuora is going to fix, or should we expect to have to adhere to this, and continue to load the entire certificate chain into our keystores, and to therefore need to update them whenever any certificate in the chain changes? We need to get this clarified before the production certificate updates in December.   Thanks,   Ben ... View more

Hi,   The notification specifically calls out "US Production Rest and API, Sandbox, and PT1" endpoints by name in the instructions ("*.zuora.com (apisandbox.zuora.com, rest.zuora.com, and api.zuora.com) ", so it seems unambiguous that we should expect the above endpoints to be updated. The amount of angst on this thread was specifically related to the fact that all of the API endpoints in all the environments were changing at once as stated in the announcement, giving no chance to test the certificates before going to production, when in fact it was apparently never the intention to update the production REST or API endpoints at all. We have all been very clear about the issues we've had with this procedure from the start. I don't see how we were the ones who were confused here. If it was known that the production API integration endpoints weren't going to be updated it could have saved a lot of grief to simply say so. Please improve the specificty of communication on upgrades like this going forward?   Thanks,   Ben ... View more

I JUST (10:37 AM EDT, October 12) ran openssl on this, here's what it's saying: ===== >openssl s_client -connect rest.zuora.com:443 -showcerts CONNECTED(00000003) depth=3 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify return:1 depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2 verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global CA G2 verify return:1 depth=0 C = US, ST = California, L = San Mateo, O = Zuora Inc., CN = WWW.ZUORA.COM verify return:1 ===== CA CERT: ===== >openssl x509 -text -in zs1 Certificate: Data: Version: 3 (0x2) Serial Number: 18:da:d1:9e:26:7d:e8:bb:4a:21:58:cd:cc:6b:3b:4a Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5 Validity Not Before: Nov 8 00:00:00 2006 GMT Not After : Jul 16 23:59:59 2036 GMT Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5 ======= SERVER CERT: ======= >openssl x509 -text -in zs2 Certificate: Data: Version: 3 (0x2) Serial Number: 03:12:e3:19:35:0d:d4:16:2a:21:18:1a:56:7c:a2:5e Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=DigiCert Inc, CN=DigiCert Global CA G2 Validity Not Before: Dec 20 00:00:00 2017 GMT Not After : Dec 21 12:00:00 2018 GMT Subject: C=US, ST=California, L=San Mateo, O=Zuora Inc., CN=WWW.ZUORA.COM ===== That's not a Comodo CA cert at the root. That server certificate still expires in December. I dunno what else to do here except to say that "rest.zuora.com" doesn't have the new cert chain yet. It's the same situation for " api.zuora.com". Am I maybe just misunderstanding the scope of the environments affected in this certificate update? ... View more

Hi,   We're still not seeing the changes for `rest.zuora.com` and `api.zuora.com` - openssl is showing the same certificate chains at this point. Is this just taking a long time to propagate?   Ben ... View more

Hi,   Can Zuora please just spin up an instance, ANY instance, of a server using the new certificates so that we can do a keystore check aginst the new certificate chain? It seems like this wouldn't be difficult to do, the server could literally just be an echo service, all we need to do is have something to validate our keystores against so we aren't testing this against live production systems. It's simply not a tolerable situation that we're going to have to ride herd on a production system for 6-8 hours in order to know if it's going to blow up or not.   Thoughts?   Ben     ... View more

So you're postponing the production updates, what about the lower environment updates scheduled over the holiday weekend? Are those postponed as well or not? ... View more

This is some confusing information, and I have a few questions:   We're pointing to the NA sandbox environment, but not using the "sandbox.na.zuora.com" endpoint. If we don't point specifically to those hosts, (i.e. we use the   "apisandbox-api.zuora.com" endpoint) will our integration be affected by the change on September 3rd, September 5th, or September 12th?   The "production" date is listed as September 12, but it includes the api sandbox ("rest.apisandbox.zuora.com") AND the production ("rest.zuora.com") endpoints. But there is also a "production date" which lists the same "rest.zuora.com"   endpoint for September 5th. If I'm reading this correctly, the sandbox environment is going to get altered either after, or at the same time as, the production environment? It's impossible to tell which date applies to which environment using the schedule as posted.    Also, September 3rd is Labor Day, and there will be massive problems with scheduling changes of this nature on that day as most of the workforce will, I imagine, be taking the day off.   Please, give some clarity to this scheule as soon as possible, as we will need to make some emergency changes to the system before next week's scheduled changes, and we need to start working on them RIGHT NOW.   Also in the future please give more time in advance of an important change like this. Posting after COB (EDT) on Friday less than a week before the first scheduled changes is not enough time in which to operate.   Thanks,   Ben   ... View more

I opened a "high priority" ticket last night at 22:46 with Zuora Support, so we're pleased it's getting looked at!   We've been keenly following the situation since then, to the point of hitting refresh on the status page every few seconds now that Zuora has an official update location for it!    🙂   B ... View more

@scottb    A little confused. The first certificate doesn't appear to be related to the current API chain.  The second is unparseable. The third looks like the Intermediary cert that signed the current API cert.   Need clarity on this ASAP please!   Thanks,   Ben ... View more

Hi Scott,    Can Zuora publish the new certificate please? We're still working through our SSL keystore implementation and will need that ahead of time.   Kind thanks,   Ben ... View more

To add on here, we currently use the RESTful Account create call to onboard new subscribers. It's highly convenient to be able to create the account, payment method, contact info, and subscription objects, plus generate and even pay the first invoice if necessary, all in one call. If Paypal isn't supported via this very useful RESTful API, then we will have to re-implement our onboarding using many SOAP calls instead of the one REST call. As Jim points out, this make the risk of error much higher.   My understanding is that Zuora would like for integrators to use the REST API, but if the major payment systems aren't supported equally, it's difficult to do. ... View more