we received a message from Apple notifying about CA certficates, old GeoTrust Global CA root certificate will be replaced by AAACertificateServices 5/12/2020. I was checking my App Engine settings and I didn't found any way to configure root certificates, so I suppose that Google manages these certificates. Am I right?
"On March 29, 2021, token and certificate-based HTTP/2 connections to
the Apple Push Notification service must incorporate the new root
certificate (AAACertificateServices 5/12/2020) which replaces the old
GeoTrust Global CA root certificate. To ensure a seamless transition
and to avoid push notification delivery failures, verify that both the
old and new root certificates for the HTTP/2 interface are included in
the Trust Store of each of your notification servers before March 29.
If your provider server runs macOS, the GeoTrust Global CA root
certificate is in the keychain by default. If your provider server
runs macOS 10.14 or later, the AAA Certificate Services root
certificate is in the keychain by default. On other systems, you might
need to install this certificate yourself. You can download the
GeoTrust Global CA root certificate from the GeoTrust Root
Certificates website. You can download the “AAACertificateServices
5/12/2020” certificate from the Sectigo KnowledgeBase website."
Kindest regards
My understanding is that Google manages the root certificate unless your app engine app is making use of a custom domain (ie is not served on *.appspot.com) and that you are not using a Google-managed certificate for this custom domain.
Still I would like to be able to formally check that things will work fine in the transition, but I did not find how to do so. Looking at the root certificate of *.appspot.com shows a Global Sign root certificate, not the legacy GeoTrust certificate Apple's APN servers are relying on currently. But as *.appspot.com is currently connecting properly to Apple's APN servers, I guess there is a matter of cross-signing or mutual recognition across certificate authorities which plays a role here.
I would also have expected Apple's sandbox APN server to transition earlier than Production for developers to see failure in their tests environment first, but I haven't seen Apple communicate any specifics on this.
Overall I'm not worried as I understand this is Apple finally migrating to a widely recognized root certificate, whereas the current one was already considered unsafe by many organizations. Also meaning we're quite lucky that connecting to APNs has been working fine out-of-the-box with App Engine until today (and hoping that will last until end of March!)
Related
I have an application with python running on a google appengine SE.
Now, some servers expect a certain root ca installed on this application.
I have found information about list of root ca supported by gcp as below.
https://pki.goog/repository/
The desirable ca was not found in the list and should be used on the application at ssl handshake somehow.
I would like to ask 2 questions.
Is there any way to set root ca or extend the lists on an google appengine SE?
Should I set a path or an environmental value to a certification file, referred by certifi module, in a source code?
To answer your questions,
The list of supported Root CAs you've mentioned pertains to Google-managed SSL certificates. Since your desired CA is not on the list, then you'll need to provision a self-managed SSL certificate. You can refer on this link for additional information/s.
Google App Engine is a managed platform, so configuring SSL certificates are done in the Google Cloud Console, or through Client Libraries and APIs. All you need is to upload the certificate, and App Engine will handle the rest.
Note that you'll be responsible in maintaining self-managed certificates, as well as renewing it once it expires.
I liked the Atom editor a lot. However, my company cannot approve it because the root certificate database cannot be managed and this compromises SSL verification process. I am not a security expert. So, I don't know what SSL verification process they talk about, and I don't know the root certificate database inside Atom.
As a comparison, NotePad++ and VisualStudioCode are approved in my company.
I wish developers in the Atom team can understand these issues and develop a solution. What do you think? Can this be done?
I'm looking to implement a running express server using https, powering an AngularJS application. Currently I have the majority of the application running just on http, but would like to switch over. This isn't a publicly available application. Am I ok to simply use self-signed certificates to implement this in our production environment? Or should I be going through a trusted certificate authority even for internal use?
Using OpenSSL seems pretty simple to generate the key and pem files... but I feel dumb when it comes to acquiring something through a trusted authority. If it's recommended that I DO in fact use a trusted CA, and not self-signed, could someone point me in the right direction on where to go for this?
The answer is "it depends".
You can certainly use self-signed certs, but you will have to manually make sure that all your endpoints are configured to trust your self-signed certs. This is what a trusted certificate authority is used for. The browser has pre-built trust for certificates issues by various public certificate authorities and, in turn, they agree to follow certain procedures related to issuing their certificates. If you go through that process, then browsers will automatically recognized and trust https connections using your certificates (assuming everything is as expected with the connection). If you don't go through that process, then you have to manually tell each endpoint that is going to access your application to trust your certificates. For closed applications with a small number of controlled endpoints, this is very feasible. For open applications or applications with a wide variety of endpoints (random browsers, phones, etc...), this is difficult.
And, you do not want to "teach" your user base to either ignore security/certificate warnings or to blindly trust things that the browser tells them might be insecure so you want to not leave this to your users - you want to pre-configure the endpoints to trust your new self-signed certs.
To give you an example, there are home security camera systems that have web access. If the only ways you need to do web access are from 2 or 3 different browsers, it's not really a problem to use a self-signed cert and configure those 3 browsers to trust it.
But, if you had some web application that many different people would access, then it wouldn't really be practical to manage the certificate trust on a rotating set of browsers and it would just be a lot less complicated and a lot more likely to be secure to use a trusted CA.
Personally I prefer using CA trusted certificates over self-signed certificates for production environments (or even developer environments) since you need to trust/add exceptions or overwrite programatic SSL checks when you are using self-signed certificates.
If you decide to use CA trusted certificates, I recommend looking into Certbot + Let's Encrypt. It is a trusted CA and supports most of the famous servers. It is also free and really easy to use. The only downside is that you need to renew the certificate every 3 months. This too can be automated depending on your platform/server.
If a certificate is from a CA (e.g. GoDaddy, Verisign), does the certificate need to be installed on a client machine?
I have a SilverLight application that needs elevated privileges and will be installed on numerous client sites. I'm also trying to minimize the installation at each of the sites (100s of deployments per site with the application hosted locally at each site).
I believe the registry changes can be deployed via a group policy update.
If the certificate still needs to be deployed, is there a value of having a certificate from a CA over a self-signed application when the primary goal is minimizing local site administration?
Yes, if a certificate is from a CA, the certificate does need to be installed on the client machine. That said however, Microsoft does already install many root certificates as well as keeps this list up to date with Root Certificate updates. See the Root Certificate Membership List
GoDaddy and Verisign are currently apart of this list, so doing an extra step should be unnecessary on a computer which is up-to-date. This is not always the case, so it still might be required on some machines.
All that said, to run Silverlight in elevated privilege mode, the user must simply click that they 'trust' the application at install time. See MSDN Trusted Applications
Taking the time of getting a signature from a CA only buys your user's a bit of extra peace of mind when the click the button as
They will see this:
Instead of:
If the goal is minimizing local site administration, then I don't see that going through the trouble of getting a certificate to sign your application would meet that goal, its only there to help provide some security for your users, which doesn't sound like it would be an issue.
Do you need to embed your site SSL Certificate inside your app if your
using HTTPS to connect to your Server.
My SSL Certificate is configure to accept *.Domain.name from GoDaddy.
Currently I have Ignore SSL enabled in order to test my application.
Anyone know how this can be done?
You can import your SSL cert onto the Android device - just look under your Settings -> Security tab. (But that's only if you need to) Your device may make you enable a form of access security afterwards (like forcing a PIN or pattern).
If you are only accessing your webserver with that cert installed, then it shouldn't need to be installed on your local hardware.