Yes. Take a look at our slide deck, 2-pager as well as our white paper. There is also a good YouTube video describing much of what the GoGetCert agent does in terms of a similar tool (ie. CertBot - common to Linux systems).

GoGetCert SCS stands for GoGetCert Secure Certificate Service. The SCS is your enterprise's central repository of certificates for all your domains. Once per day each server in your enterprise calls the SCS to "check-in" (ie. verify the agent is still running on that server) and download a new shared certificate (if one is available).

No.

Microsoft Windows Server 2012, 2016, 2019, 2022+.

No. Your enterprise will have its own dedicated SCS instance. No one else can use it.

No. Only those private keys acquired today and awaiting distribution tomorrow exist on the SCS. Once a domain's certificate is distributed to that domain's servers, its private key is destroyed on the SCS. All that remains of your certificates on the SCS are public keys only.

No. The GoGetCert agent software uses few resources. In fact, the agent EXE (ie. "GoGetCert.exe") is significantly smaller than the average Android app on your phone. That said, you will need a dedicated virtual machine for the GoGetCert SCS. Either you can host it within your own enterprise data center (or within whatever cloud service you prefer) or GoGetCert can host it for you on AWS (for a fee).

There are no ongoing tasks for your team. Once your team successfully installs the GoGetCert agent on a server, that server is now in "set it and forget it" mode. Even GoGetCert's many verbose and easy to read process logs are automatically cleaned up daily (logs are retained for 60 days, by default).

Simply put, no. The AKV is a globally known resource. Everyone knows what it is, where it is and how to get to it. It's the same for everyone. The SCS is different for everyone. Its location on the internet is known only to your enterprise and no one else. And even if someone does learn the location of your SCS, a firewall blocks all IP addresses to it except yours. What's more, only callers with the correct digital certificate (one that's regularly changing) can access the SCS (no usernames, no passwords, no tokens). By comparison, the AKV is a gigantic honeypot eyed by every hacker on the planet and accessible by users with a username and a password.  While the AKV keeps private keys accessible indefinitely, the SCS allows access to its private keys for only 1 day - after that they're destroyed. And during that 1 day the private keys are accessible only by the heavily secured GGC agents. Finally, and most critically - unlike the AKV, enterprise IT staff never have access to private keys on the SCS.

While Microsoft is indeed a great company with great security, it has so many balls in the air that it is constantly struggling to secure its own systems (see "Russia hacks Microsoft: It's worse than you think"). Microsoft must be everything to everyone while GoGetCert does just one thing - keeping the keys to your kingdom absolutely safe and unhackable.

Detailed yet easy-to-read logs are available on every server where the GGC agent runs. The same logs can be emailed daily as well, assuming the recipient has subscribed to that. The GGC agent has robust error handling and almost always self-corrects on its own.

We monitor all servers and all domains. If we see an issue, we correct it and notify the customer. If their involvement is needed (almost never), we let them know what to do. If they have questions or need help adding new servers to the fray, they can call us or email us 24/7. That said, our team always knows of any certificate issues before you do. We monitor the servers in your enterprise from their daily check-ins and check-outs with the GoGetCert SCS. We will call you when we see an issue requiring your team's involvement (very rare).

Let's Encrypt is supported out-of-the-box. The GoGetCert agent can be configured to work with any other ACME (Automatic Certificate Management Environment) protocol capable CA as well. Certificates from non-ACME capable certificate authorities can also be used as overrides.

Yes. Take a look on GitHub. The "stand-alone" version of the GoGetCert agent can fetch, install and bind any number of certificates for a single server. If you want several servers to share the same certificates, that's when you need the GoGetCert SCS.

Assuming there is already an enterprise certificate on the server (eg. a wildcard certificate), it takes less than a minute to install the "GoGetCert.exe" software on that server. If there is no certificate already installed, then a "GoGetCert Setup Certificate" must be used instead. That adds about a minute to the setup time.

No. The GoGetCert agent is identified using the same certificate it regularly renews for the domain. The process is bootstrapped using a common certificate (eg. a wildcard certificate) already in use by your enterprise and installed on the same server. Alternatively, a "GoGetCert Setup Certificate" - created by GoGetCert specifically for your enterprise - can be used as the bootstrap certificate instead.

No. Your SCS instance is locked down by an instance independent firewall. The firewall is configured to allow access only to a subset of your enterprise public IP addresses.

During setup of the GoGetCert agents, the SCS is informed where to securely archive copies of your certificates (somewhere on your own servers). It's entirely up to you as to where to place them per domain - or if you want archived certificates at all for that domain. Certificate files (PFX or PEM) use 10-20 character random passwords for archived certificates. No password is ever used twice and GoGetCert must be contacted by phone (by a known enterprise contact) to provide a certificate password (for a nominal fee). Alternatively, you can trigger a new certificate for a domain so that all existing servers as well as the new server can get it at the same time.

There are dozens of GoGetCert notification types your enterprise personnel can subscribe to. These include notifications for daily server check-ins and check-outs, notifications when a new certificate is added to the SCS repository, when a certificate is downloaded to a server, when it's installed on a server, and so on. There are also notifications about automated movement of certificates to your load balancer, assuming your load balancer supports that. If not, there are alternative notifications to your load balancer admin to manually pickup new certificates when they arrive. Finally, there are failsafe warnings about certificates soon to expire.

They would, if they use a PaaS ("Platform as a Service") for their websites. Fully automated certificate management offered by cloud services only work with PaaS apps. Most large enterprises (using .Net) still run IIS on virtual machines for their websites since VMs provide the highest level of control over the performance and functionality of their web applications (eg. allowing certificates to be bound to several different IP addresses and ports on the same server). That's where GoGetCert comes into play. That said, companies using PaaS web apps can still benefit from GoGetCert when they need to offer password-less authentication to their customers.

While MS solutions work and are comprehensive, they are also often overly complex (like ADFS, for example). Here's the minimal effort required to get ADCS going:

‍https://www.sysadmins.lv/blog-en/certificate-autoenrollment-in-windows-server-2016-part-4.aspx

‍Then you have the problem of monitoring and error handling. Of course, any large enterprise has the resources to handle all of this internally (even for hundreds of domains), but then they have the ongoing problem of keeping specialists on staff for that purpose.

We offer simplicity and the staff to keep on top of everything - and to correct any problems long before they become known to enterprise customers. All that said, you know something's not right when Microsoft still has certificate expiration issues of its own - even after ADCS has been available for many years.

If the enterprise is running IIS in VMs (in the cloud or anywhere else), the GoGetCert agent runs in each. Alternatively, the agent can run in a single enterprise VM and place the certificates it acquires into the enterprise's key vault. Any "Azure Web Services" based applications can then get their certificates from there (as usual). This is the approach used when such PaaS apps need to offer password-less authentication to its consumers.

For many apps a load balancer cert alone will suffice, but we also support the common use case where the LB must decrypt and reencrypt user session, which requires the same certificate on each server in the LB pool, a certificate that matches what's on the LB. There are also many scenarios in UAT environments where no LB is actually in use, not to mention the need to test or otherwise access production applications independent of the load balancer.