FAQs - AutoCertNow

Need Help? Start Here.

Are there more technical details on how all this works?

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

What is the AutoCert SCS?

AutoCert SCS stands for AutoCert 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" (i.e., verify the agent is still running on that server) and download a new shared certificate (if one is available).

Is there a limit to the number of servers per domain or the number of agents that can be installed?

What operating systems does the AutoCert agent support?

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

Is the AutoCert SCS shared by your other customers?

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

Will all of my private keys be centrally stored on the SCS?

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.

Do we have to add any hardware to our servers to run AutoCert?

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

Are there installation tasks or ongoing tasks that our team is responsible for completing?

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

Isn't the Azure Key Vault (AKV) more secure than the GGC SCS?

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 AutoCert does just one thing - keeping the keys to your kingdom absolutely safe and unhackable.

In a complex tech stack involving security, do you provide additional tooling to offer transparency in automated processes? Insights? Error/failure handling? Actionable and/or automated logic for such?

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.

How do you manage enterprise-level support?

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 or email us. 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 AutoCert SCS. We will call you when we see an issue requiring your team's involvement (very rare).

Which CA sources (certificate authorities) do you support?

Let's Encrypt is supported out-of-the-box. The AutoCert 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.

Is there an open source version of your software? Limitations?

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

How long does it take to install the AutoCert agent on a server?

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

Does the AutoCert agent require credentials (i.e., username, password/token) to access the AutoCert SCS?

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

Is my enterprise SCS generally accessible over the internet?

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.

What if I need a certificate (one already in use) to be quickly installed on a new server?

During setup of the AutoCert 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 AutoCert 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.

What notifications are sent during processing or when certificates are about to expire?

There are dozens of AutoCert 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 pick up new certificates when they arrive. Finally, there are failsafe warnings about certificates soon to expire.

Why wouldn't companies use the certificate management tools offered by cloud services?

They would, if they use a PaaS ("Platform as a Service") for their websites. Fully automated certificate management offered by cloud services only works 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 (e.g., allowing certificates to be bound to several different IP addresses and ports on the same server). That's where AutoCert comes into play. That said, companies using PaaS web apps can still benefit from AutoCert when they need to offer password-less authentication to their customers.

How is your solution different from Microsoft's own ADCS based automated certificate renewal?

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.

How are cloud based (Windows) servers supported, also taking into account Azure Key Vault and equivalents?

If the enterprise is running IIS in VMs (in the cloud or anywhere else), the AutoCert 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.

I'm a Linux guy and I typically do certs on load balanced setups (where the balancer itself has the certs, and VMs hold the applications). Does Windows not offer similar solutions to minimize problems like these?

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.

Is the giant DigiCert corporation really trying to put you out-of-business?

Apparently so. Our domain name used to be "GoGetCert.com." Take a look at this cease & desist letter and see: "DigiCert demands ... immediately and forever: ... transfer to DigiCert any and all domain names that include GOGETCERT..."

Do you believe the gall? Ask yourself, what are they afraid of, really?