question

Hi Jon, Welcome to the forums! I suspect the issue is that you need to include the Root CA cert within your cert file that is presented by your webserver. From: https://www.sslshopper.com/ssl-checker.html#hostname=jspeis.com ...it appears that you have the server and intermediate certs installed correctly, but not the Root CA cert. Although Alexa uses the pool of CA's from Mozilla, it seems to not apply them (like how your browser might do), and so you need to add it to the PEM file. I hope this helps - let me know if you need a hand! Cheers, James

Hi James, Thanks for your response. I had updated my cert and it looks like the root cert shows up now as part of the chain at https://www.sslshopper.com/ssl-checker.html#hostname=jspeis.com but I'm still getting the same error. Is it installed correctly now? Thanks again for your help! Jonathan

Hi Jon, Yup, the cert looks good and the root ca is in the mozilla bundle. Is your app endpoint URL that you've assigned in the developer portal inclusive of the www subdomain? I ask because your cert common name (CN) is www.jspeis.com and so I think it would need to be something like: https://www.jspeis.com/path/to/app (Don't reveal the path herein of course - keep that private but just double-check) Also - can you confirm whether you're seeing the requests in your nginx logs? Oh, and confirm you're actually serving from nginx too :) Alexa doesn't support SNI (yet) - so most cloud based providers (e.g. App Engine) will NOT work correctly when presenting SSL certs. Sorry - I'm not sure what level of experience you have so I might be asking really silly questions of you! :) Cheers, James

Just to add - looks like you have set cert SAN (Subject Alternative Name) value to: DNS Name: www.jspeis.com DNS Name: jspeis.com ...which is a good thing, so can probably serve off both naked domain and www subdomain - I have the same set and serve from the naked domain fine, so your app path could be something like: https://jspeis.com/path/to/endpoint or whatever

Hi James, I am using nginx and I have tried with both www.jspeis.com and jspeis.com but no luck. Seems strange to me because when I select "My development endpoint has a certificate from a trusted certificate authority". I don't see any record of an attempted HTTP call in the nginx logs. Nothing in the access or error logs, but I still get the SSL error message on my phone Echo app. When I switch to self-signed cert, I see the succesful HTTP POST request in access.log. Any idea what it means that I'm not seeing anything in nginx? Best & thanks again! Jonathan Message was edited by: Jon

I am no expert in these matters, but when I check your domain ( https://www.jspeis.com with my browser (Chrome v 43.0.2357.124 m) I get a yellow warning triangle on the address bar (just to left of 'https://....) and the following text warnings: This site uses a weak security configuration (SHA1-Signatures), so your connection may not be private. The identity of this website has been verified by StartCom Class 1 Primary Intermediate Server CA but does not have public audit records. This site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it. .... as I say I am no expert so perhaps that has no bearing to the problem you are experiencing.

It's possible that you won't see anything in the access/error logs if the handshake failed before nginx gets to process the HTTP request, so it makes sense. If you wanted, you could use something like tcpdump or ssldump to determine whether *any* packets are coming to your server against 443 (and it should capture the handshake). Greg might have a point - maybe Alexa is just picky on the certs needing to all be >=256? I am seeing an issue that you've a self-signed root certificate: openssl s_client -connect jspeis.com:443 ... depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain ... For my SSL cert - I have server + intermediate + root, but my root isn't self-signed (I know, this is confusing). Greg (or anyone else!) - if you get a second - please could you try your domain in: https://ssltools.websecurity.symantec.com/checker/views/certCheck.jsp ...and see whether you get a warning like: Recommendations Root installed on the server. For best practices, remove the self-signed root from the server. I'm seeing that warning on Jon's SSL cert ( jspeis.com), but not on mine, and my 'root' cert is not being reported as self-signed. [1] https://developer.amazon.com/public/solutions/devices/echo/alexa-app-kit/docs/developing-your-app-with-the-alexa-appkit

Hi Jon! I noticed your cert is updated with a new common name, etc. and wondered if you were successful now or not? The Symantic SSL checker is still complaining about the self-signed root CA (AddTrust External CA Root) being present in your chain. Maybe worth trying without it perhaps? Not sure if it'll help, but here's the commands I used to generate my CSR and create my own chain: openssl req -nodes -newkey rsa:2048 -sha256 \ -out domain.net.csr \ -keyout domain.net.key \ -subj "/C=US/ST=California/L=San Francisco/O=James Chivers/OU=James Chivers/CN= domain.net" cat domain.net.server.crt domain.net.intermediate.crt domain.net.root.crt > domain.net.chained.crt I then dropped domain.net.chained.crt along with domain.net.key into /etc/nginx/ssl The relevant part of my nginx configuration for this server looks like: listen 443; server_name domain.net; ssl on; ssl_certificate /etc/nginx/ssl/domain.net.chained.crt; ssl_certificate_key /etc/nginx/ssl/domain.net.key; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES"; ssl_prefer_server_ciphers on; Not sure how much that'll help - but let me know if you're still having issues and I'll do what I can :) Cheers, James

Hi James, I wasn't able to get things working with StartSSL -- but I used a free trial certificate from Comodo and that worked fine! (even with the root certificate is installed warning). I'm guessing the issue may have been specific to something with my StartSSL configuration. I noticed that the Startssl root certificate seemed to use 128-bit key .. maybe the problem was with the weak key? Thanks again for your help Jonathan

Hi Jon, Great to hear you got moving with a new cert; it's all downhill from here :) Yup, Greg could be right - maybe the weaker cert is an issue for Amazon - although they're not exactly outlawed and so _should_ be acceptable still imo. Looking forward to seeing what you build! Cheers, James