|Frequently Asked Questions|
Questions about AutoSSL
Questions about SSL
When a CA receives a certificate signing request, it must verify that the sender of the request has both legal control over the domain represented and the authority to make that request. (For example, not all Amazon.com employees are authorized to create an amazon.com SSL certificate.) This means that the process of signing a certificate stops while the CA vets this information, either by telephone, e-mail, requesting supporting documentation, or another method that requires user interaction. Since the user must do something in the middle of the process, it cannot be completely automated.
In contrast, AutoSSL was designed explicitly to automate the process of creating and signing certificates. AutoSSL does not require human interaction for vetting since a trusted source created the certificates. Removing this vetting requirement enables us to completely automate the process, making it ideal for home users.
While someone could reverse-engineer the AutoSSL Agent, it would be pointless. The value of AutoSSL is not only in the AutoSSL Agent but also in the connection with an AutoSSL Server. A pirated AutoSSL Agent is worthless because an AutoSSL Server cannot authenticate it and therefore will not service it.
The AutoSSL Server is a Java application that can be deployed on a wide variety of operating system platforms. It runs efficiently on standard off-the-shelf hardware and can simultaneously service many customers with mimimal computing power.
Not really. AutoSSL certificates are not suitable for e-commerce sites because they are created for subdomains shared by many customers. This is actually an advantage for a home user who wants a server accessible on the Internet, because there is no extra hassle or expense of registering your own domain name.
AutoSSL certificates are not appropriate for an e-commerce site that needs to present a consistent brand to its users. A user who shops at a site will expect to enter a credit card number at some subdomain of the site. For example, a shopper at ecommercesite.com will expect to enter a credit card at a subdomain such as secure.ecommercesite.com. If a completely unrelated domain opens (which would happen with an AutoSSL certificate), the shopper may become suspicious and cancel the transaction. Therefore, it is unlikely that e-commerce sites will be penny-wise and pound foolish: they will probably prefer to spend more money for a conventional, properly branded SSL certificate. As they tend to have more IT resources than the average home user, installing this certificate should not pose a problem.
The speed for provisioning and deploying an AutoSSL certificate depends on many factors. The most important factor is the performance of the platform running the AutoSSL Agent (and the Web server that it ultimately secures). In our tests using consumer-grade networking equipment, AutoSSL deployed a certificate within two minutes without any action required from the user.
As a software company, we know that our innovative ideas and intellectual property are our most valuable assets. We have invested a lot of time and energy to develop our technology, and we will protect it in every possible way. Sericon Technology currently has several patents pending for its AutoSSL technology and related products.
No, SSH is not an appropriate alternative to AutoSSL. While SSH is a good protocol for establishing secure links between clients and servers on the Internet, it does not address the same issues as AutoSSL:
VPNs are systems typically used by companies to enable workers to remotely access local resources, and are often used for telecommuting. While VPNs are very secure, they are very complex to deploy and have the same drawbacks as SSH (see above) in addressing the issues that AutoSSL solves.
Note: Many VPNs use SSL as the underlying technology for providing encryption and secure transmissions. For those systems that use SSL, AutoSSL is actually an ideal method for deploying the SSL certificate to these servers.
The cost of using AutoSSL depends on many factors, such as whether the AutoSSL certificates are signed by a trusted CA or simply signed by a private root.
Regardless of the conditions, we are commited to keeping the cost of a certificate to be as low as possible. Consumers are now used to paying for security for their computers, such as anti-virus software, but there is a limit to what they are willing to spend. Pricing for AutoSSL will ensure that these users will feel their money is well spent.
SSL certificates have expiration dates, and they typically expire after one year. This means that even though the price will be kept low, consumers will have to renew their certificates every year. AutosSSL encourages customers to renew their SSL cerificates, because it links them to hostnames and dynamic DNS resolution.
Sure. If you already have a way to assign hostnames and maintain the correct DNS bindings, you can use AutoSSL to just provision SSL certificates.
To use SSL, a Web site must have an SSL certificate that contains the information necessary for the encryption. It also contains information that identifies the owner of the Web site and an unforgeable statement from a trusted party that the information contained in the certificate has been verified as true. This trusted party is called a Certificate Authority (CA), and charges a fee to sign certificates and assert their authenticity. Popular CAs include VeriSign, Comodo Group and GoDaddy.
For more information about SSL, please see the Sericon Technology white paper, Introduction to SSL.
SSL has existed as a protocol for Web site security for 15 years, and the underlying technology on which it is based is still as reliable and secure as when it was invented. If someone could develop a method for cracking SSL, it would be very valuable to thieves or foreign governments. For this reason, many people have tried to find a method for cracking SSL and they have all failed.
The fact that no one has been able to defeat SSL is not proof of its invincibility, but it demonstrates why so many people and organizations trust it. It is not likely that anyone will develop a general method for defeating SSL, and if someone does, it would certainly be front page news.
In December 2008, an international team of security experts showed that under the right conditions, they could create a "rogue CA certificate" that would be trusted by all browsers, and that could be used to sign any other certificate. This situation would put the entire Internet security infrastructure at risk if this research were to be used in a malevolent way.
The system that they developed took advantage of some obsolete security algorithms that have been demonstrated to be questionably secure, and the few places that still use them have been fixed so that this security exploit is now only of academic interest.
While some believe that this points to a fragile infrastructure, we agree with most that it shows how robust SSL really is, and that it can evolve with cutting edge technology.
To learn more about this work, see MD5 considered harmful today.
In the world of computer security, they are many breakthroughs and systems that companies have created with great promise and fanfare that ended up as failures. Unless these systems are thoroughly examined by a large team of experts in cryptography, it is likely that holes in the security will quickly be found by the legions of hackers who attack such products like a pack of wolves. In the past, we've seen catastrophic failures such as:
The above systems show that no system for security should be considered really secure until it has been used for a while, and people have tried to subvert it. It is important to understand that AutoSSL does not affect how SSL works to secure web servers. AutoSSL simply addresses how SSL certificates are generated and deployed. This means that an AutoSSL certificate is as safe and secure as one installed in an e-commerce site by IT professionals.