At present, people who are running their own webservice that they want Alexa to call out to have to meet some extremely strict SSL requirements. As a result, the SSL requirements are a blocker for many people who would like to develop using the Alexa Skills Kit. The argument in favor of the SSL requirements is that it provides a modicum of security when applied throughout the application stack. Unfortunately, we've reached a point where the standard operating procedure for developers is to do token appeasement of this requirement in a way that doesn't actually secure things. This approach is to route through a Lambda function which then calls out to the original webservice over http. Because HTTPS is terminated at the Lambda function, which is added in for this exact purpose, the SSL functionality is worthless. When the "workaround" for a process becomes ubiquitous as the de facto way to implement that process, it may be time to consider why that process exists in the first place.
All Amazon need to do to fix this issue is to create a [i]specific[/i] set of instructions for doing this. Their tutorials tell you how to set up a skill on Elastic Beanstalk. If they added instructions on how to use a [i]specific[/i] certificate provider, what sort of certificate to buy, and how to set it up on Elastic Beanstalk, that would do. Better would just to accept the certificate used on Elastic Beanstalk as a special case. Then no work is necessary for the tutorial case. And, in the end, a hyper-security SSL layer between Alexa and a 3rd party developer is a feature really just protects the 3rd party developer. (Unlike the Echo<->Alexa connection, which really does need top security) It stops your skill from being abused. Well, I guess a man-in-the-middle attack could send disruptive text for the Echo to say. But it really isn't a huge [i]customer[/i] security issue. So even just relaxing the requirement would be a reasonably viable option.