Every day developers handle multiple levels of abstraction, navigate multiple, syntactically diverse languages and weave together all the other 300 million things that need to ship apps. So why in the name of Vint Cerf is setting a site up with SSL so painful?
Aside from the well described horrific technical reasons, a major painful contributing factor is that the process of adding a SSL Certificate to a site is going to require multiple people at different levels of a company working in tandem - in other words: herding cats.
These are those people:
One person is going to need access to (or to generate) a new key that can be used to generate a Certificate Signing Request (CSR) that will then need to be submitted when the certificate is purchased. In larger organizations this is often the overtasked Chief Security Officer or Chief Technology Office who is trying to keep control - or at least awareness - of all of the different keys used for access to sites, code signing and certificate generation.
A tricky aspect of this is that the certificate signing request process is constantly in flux as attacks unfold, computers increase in speed and capability and weaknesses (like Heartbleed and POODLE) are found.
In the last year, certificate signing requests were required to bump up their key-sizes to at least 2048-bit (making most old blog posts and guides obsolete). In the next year SHA-1 is being phased out for SHA-256 signing of CSRs and if you choose the wrong option when generating your request you likely won't find out until you start getting end users complaining about frightening error messages when they access your site.
It seems obvious to say, but commercial certs cost money. If you're a freelance consultant you'll likely request that your client purchase the certificate (doing an email dance back and forth, that might include you trying to explain what the difference between a private and public key is and then having to redo everything because they picked IIS as the target server for the cert because they "thought we used Microsoft").
In a larger organization you might need someone from accounting to handle the purchase who will demand Purchase Order numbers and cost justifications as to why you aren't using the service with the incredibly misleading Superbowl ads.
If you're lucky enough to be using Heroku, you can skip this step and use their add-on ecosystem for its consolidated billing. Which counts as one "vendor" to corporate accounting systems. This makes it an order of magnitude easier to provision another add-on to your existing Heroku account than to a new external company.
Worse, SSL certs costs tend to fall into a gray area of "too small to remember". If they cost $10,000 dollars a year, they would be planned for, budgets allocated, signatures collected, etc. But, since in most cases they cost less than the monthly bagel budget, nobody cares.
After the CSR has been generated and the certificate paid for, the request to issue a certificate must still be approved. The most common approval pattern is similar to a password reset email loop, where an approval email with a unique link is sent to an individual who is definitively associated with the domain that as certificate is being issued for.
To find an acceptable email address for a domain, Whois records are examined to find the technical and administrative contacts for a domain. This is less straightforward than it sounds as those records only exist for .com TLDs - other countries and TLDs may or may not return any email addresses at all (like the very common .io TLD). Further complicating the situation are private domain registration services.
Private registration varies between domain registrars: some simply substitute the emails present on the domain record with proxy email forwards (email@example.com blindly forwards all email to firstname.lastname@example.org) - these typically work fine.
However, some private registrars restrictions are more elaborate and instead of simply forwarding email - they auto-respond with a request to complete a form, or some other tactic meant to mitigate spam. Unfortunately, these are a hard roadblock to receiving an automated approval email from a certificate authority.
To receive the approval email, private registration must either be turned off or the email can alternatively be sent to a generic address like 'email@example.com' or 'firstname.lastname@example.org' - which may need to be put in place.
After approval, you should receive the new SSL certificate which will need to be installed. Depending on where the certificate was purchased still needs to be linked with any intermediate certificates and installed into your web server. This needs to be done to maximize the number of devices and browsers that can connect to your site successfully. In particular, mobile device browsers are very sensitive to differing certificate chain issues.
It is at this point - on the cusp of success - that this individual will complain voicferously about all of the choices you have made up to this point: "Why can't we just use a self-signed certificate that will present website visitors with an easily understood message about keysizes, security measures, trust and will in no way scare them away from our site?"
Different server setups may require additional changes to be made to the DNS of a site. Larger websites use dedicated SSL Terminators.
Heroku's SSL Endpoint Add-on is perhaps more accurately described as a 'SSL Enabled Load Balancer' though they don't describe it that way in their documentation. As such, to enable SSL on your Heroku site it's necessary request that the existing DNS settings for your site be modified to match the new endpoint.
Your endpoint sits in front of your provisioned web dynos and handles the SSL communications (taking a load off of the dynos) as well as maintaining a singular point for both HTTPS and HTTP traffic to flow over. Heroku is currently deploying a variety of different domain schemes - but in almost all cases you'll need to make additional DNS modifications to support your new SSL Configuration.
Since SSL certificate settings have become such a moving target, people are issuing them for shorter and shorter periods of time. While it is still technically possible to request a 3 or 5 year certificate for a site, practically it is not worth it as you are near guaranteed that you'll need to make multiple changes prior to its expiration.
An interesting case is to look at Google, who have now moved to 3 Month expirations on all of their certificates in order to better position themselves to respond to threats and changes.
Given that, you'll probably need to redo the above process at least once a year until you give up and take a job herding goats on a ranch in Montana.