Wildcard subdomains on appengine over https on firefox
Asked Answered
G

3

7

When I go to https://wild.rileylark.appspot.com with chrome, I get the nice "this is going great" icon. When I use firefox 4, I get the "omg, you're effed" message:

wild.rileylark.appspot.com uses an invalid security certificate.

The certificate is only valid for the following names: *.appspot.com , *.*.appspot.com , appspot.com

  1. Is this normal?
  2. Anything I can do to fix this?
Grondin answered 19/4, 2011 at 20:37 Comment(5)
check this hanselman.com/blog/…Tegantegmen
But it looks like the certificate appengine is using explicitly covers both *.appspot.com and *.*.appspot.com... I'm stumped!Grondin
At a guess, Firefox doesn't interpret the double-wildcard address properly. :/Dearden
By the way, "SSL access on non-appspot.com domains" is currently on GAE's on deck roadmap: code.google.com/appengine/docs/roadmap.htmlClassis
Yeah, it's been due "EOY 2010" since MOY 2010, so I'm moving forward without any assumptions about that. The second that's available, we'll switch. Hopefully it will support wildcard SSL certs!Grondin
F
6

So the specific condition here is that the name on the certificate is *.appspot.com, and *.*.appspot.com appears within the cert's Subject Alternate Names field.

A rejected Chrome bug covers this exact scenario. In it, the respondent indicates that this is deliberately unsupported in Chrome, points to Firefox source code suggesting the same, and asserts that both are following the IETF's recommended implementation of RFC 2818.

Ferricyanide answered 29/4, 2011 at 14:23 Comment(0)
P
12

The workaround to this limitation is now described in docs: use -dot- in place of dots between your subdomain names, e.g. https://wild-dot-rileylark.appspot.com

Parisi answered 23/4, 2012 at 15:59 Comment(1)
This is the simplest workaround and solves the problem instantly without any reconfiguration. At first I thought that it needs some tweaking in the yaml to activate. Thanks for the hint.Ironmaster
F
6

So the specific condition here is that the name on the certificate is *.appspot.com, and *.*.appspot.com appears within the cert's Subject Alternate Names field.

A rejected Chrome bug covers this exact scenario. In it, the respondent indicates that this is deliberately unsupported in Chrome, points to Firefox source code suggesting the same, and asserts that both are following the IETF's recommended implementation of RFC 2818.

Ferricyanide answered 29/4, 2011 at 14:23 Comment(0)
P
1

Please note that in April of 2013, Google stopped issuing SSL certificates for double-wildcard domains hosted at appspot.com (i.e. ..appspot.com). If you rely on such URLs for HTTPS access to your application, please change any application logic to use "-dot-" instead of ".". For example, to access version "1" of application "myapp" use "https://1-dot-myapp.appspot.com" instead of "https://1.myapp.appspot.com." If you continue to use "https://1.myapp.appspot.com" the certificate will not match, which will result in an error for any User-Agent that expects the URL and certificate to match exactly.

Ref: https://cloud.google.com/appengine/docs/python/modules/

Penetrate answered 20/11, 2014 at 17:58 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.