We run a cloud platform with subdomains for each customer (similar to how Shopify has mystore.myshopify.com).
It currently runs as a Gen1 app, and will likely need to be upgraded soon.
According to the docs however, it's not possible to use wildcard subdomains due to an issue with Let's Encrypt?
https://docs.convox.com/deployment/custom-domains
Does this make Convox a non-option for us moving forward?
We also offer customers the ability to use a custom domain (also similar to Shopify) but would this mean we would need to configure each domain with Convox on the convox.yml level, and have the customer sent a Let's Encrypt validation email?
LetsEncrypt doesn’t use validation emails. As long as the DNS resolves to the Rack router, LetsEncrypt will issue the cert.
So while you would have to specify each sub-domain in their convox.yml, the email thing isn’t an issue. You can specify the domains through the use of an env var which they can update rather than actually changing the file each time.
You could also use Gen2 which has ongoing support and development. Gen2 and Gen3 are just different pathways to achieve relatively the same thing. https://docsv2.convox.com/gen1/ssl
Related
I guess that's a very simple task, but I can't manage to have SSL work on gitlab pages. Gitlab pages documentation is too vague for me.
For example, when they say "Make sure your domain doesn't have an AAAA DNS record." does that mean the subdomain (say gitlab.mysite.com) doesn't have a AAAA record. Or does it mean my whole DNS configuration shouldn't have such a record?
Also if that's the later, how can I manage to make this work?
Maybe someone has a source to a good tutorial for this because I really struggle finding simple information (not assuming any prior knowledge about SSL/gitlab).
I just went through the whole process beginning to end and set up a GitLab Pages website on a custom domain with a Let's Encrypt certificate -- it worked like a charm.
I had to:
a) set up a TXT record to verify domain ownership, and
b) add an A record to point at the GitLab Pages IP address (since my domain DNS management provider didn't allow me to set up a domain-level CNAME)
After this, GitLab went and fetched a Let's Encrypt certificate for my Pages web site.
I didn't have a AAAA record, so that didn't come into the picture.
As per GitLab Pages documentation section GitLab Pages integration with Let's Encrypt,
Caution: This feature covers only certificates for custom domains
Issue 3342 is open to add support for sub-domains.
If you are still having trouble, let me know, I'd be happy to help with this.
I'm trying to use Heroku's Automatic Certificate Management to set up SSL for my site. My app is on heroku at myapp.herokuapp.com, and I currently have Subdomain Forwarding set up so that http://www.myapp.com properly shows my app.
What I want is to have my site hosted at https://myapp.com.
I ran heroku certs:auto:enable, but it shows:
=== Automatic Certificate Management is enabled on myapp
Domain Status
───────────────── ───────────
www.myapp.com Failing
Running heroku domains shows:
=== myapp Heroku Domain
myapp.herokuapp.com
=== myapp Custom Domains
Domain Name DNS Target
───────────────── ───────────────────────────────
www.myapp.com www.myapp.com.herokudns.com
Right now, in Google Domains, I have a Subdomain Forward from #.myapp.com to http://www.myapp.com. I also have a Custom Resource Record with the name www, type CNAME, and data myapp.herokuapp.com..
What do I need to change in my setup so that I can host my site at https://myapp.com?
Unfortunately, Google Domains does not support the ANAME or ALIAS record. You must use one of these for your apex domain. Here's the full list supported by Google Domains.
https://support.google.com/domains/answer/3290350
Heroku has a list of DNS providers that support the ALIAS or ANAME records here: https://devcenter.heroku.com/articles/custom-domains#add-a-custom-root-domain Personally, I use DNSimple and have had great success with them.
The CNAME target needs to be www.myapp.com.herokudns.com. In your question above you only have the apex record in your DNS in myapp.com.herokudns.com. If this is not the case can you share the domain so I can dig the record for more information?
I've had the same problem with Heroku and other PaaS providers over and over: depending who provides and manages the DNS for your domain you may or may not able to use a CNAME or ALIAS record on the naked domain. That's why we've created a simple service to solve this by applying a simple SSL redirection from the naked domain to the "www" under SSL, without changing your DNS management provider: NakedSSL will give you an IP and will create and host an SSL certificate for your naked domain (https://yourdomain.com), redirecting it to the HTTPS URL that you want (most likely "https://www.yourdomain.com").
Disclaimer: I'm obviously part of the team that created NakedSSL. I hope you don't take this as self-promotion (anyway we offer it for free for 1 domain, which totally fits the needs of 95% of developers/hobbyist out there), but as a way to deal with this annoying situation in an easy way.
My client owns "domain.com". We need to give various applications friendly names for internal and external access. The applications are WCF web services and MVC web applications with varying levels of authentication (Windows auth within and across AD domains and plain text authentication). It looks a little like this:
UAT Environment
service1.uat.services.domain.com
service2.uat.services.domain.com
service3.uat.services.domain.com
service4.uat.services.domain.com
application1.uat.apps.domain.com
application2.uat.apps.domain.com
Production Environment
service1.services.domain.com
service2.services.domain.com
service3.services.domain.com
service4.services.domain.com
application1.apps.domain.com
application2.apps.domain.com
We're likely to have a LOT more sub domains, and everything needs to be secured with SSL.
We've changed our minds on how to configure this a number of times, but now we've hit a possible restriction. We thought a wildcard SSL certificate might work, but apparently they only work to a single level of subdomain i.e. *.services.domain.com.
Because of budget, we'd like to register a single wildcard SSL certificate and apply it to multiple servers (belonging to multiple AD Domains, and also a few servers in our DMZ).
This morning I had an idea, but I don't know enough about this stuff to make a definite decision. Do any of you foresee any restrictions on using the following naming convention instead of the above?
service1-uat-services.domain.com
service2-uat-services.domain.com
service3-uat-services.domain.com
service4-uat-services.domain.com
application1-uat-apps.domain.com
application2-uat-apps.domain.com
service1-services.domain.com
service2-services.domain.com
service3-services.domain.com
service4-services.domain.com
application1-apps.domain.com
application2-apps.domain.com
That way, we can register a wildcard for *.domain.com and use a single level subdomain for each application / service, but still allow us to keep everything logically separate. Are there any technical issues anyone can identify using this set up?
There shouldn't be any problem with that.
About a year ago I have installed mod_pagespeed on my VPS server, set it up and left it running. Recently I was exploring files on my server, went to pagespeed cache folder and discovered some strange folders.
All folders usually named this way ,2Fwww.mydomain.com or ,2F111.111.111.111 for IP addresses. I was surprised to see some domains that does not belong to me, like:
24x7-allrequestsallowed.com
allrequestsallowed.com
m.odnoklassniki.ru
www.fbi.gov
www.securitylab.ru
It looks like something dodgy is going on, was my server compromised, is there any reasonable explanation?
That does look peculiar. Everything in the cache folder should be files that mod_pagespeed tried to rewrite. There are two ways that I know of that this can happen:
1) You reference some third-party resource (say an image from another domain, or google analytics script) and you have explicitly enabled rewriting of that domain with ModPagespeedDomain www.example.com or ModPagespeedDomain *.
2) If your server accepts HTTP requests with invalid Host headers. Try (for example) wget --header="Host: www.fbi.gov" www.yourdomain.com/foo/bar.html. If your server accepts requests like that it may be providing mod_pagespeed with an incorrect base domain, and then subresources would be fetched from the same domain (so if www.yourdomain.com/foo/bar.html references some.jpeg, and your server accepts invalid host headers, we could fetch www.fbi.gov/foo/some.jpeg as the resource). There was a recent security release that makes sure all of these subrequests are done against localhost (not arbitrary third-party websites). Please see: https://developers.google.com/speed/docs/mod_pagespeed/CVE-2012-4001
You might want to look through these folders and see what specific resources are in there. I think that the biggest concern you should have is that someone might be trying to perform an XSS attack on your users or maybe a DDoS attack against another website (like www.fbi.gov), using your server as one vector. I do not think that these folders are indicative that your server itself is compromised.
If you would like to discuss this more, https://groups.google.com/forum/?fromgroups#!forum/mod-pagespeed-discuss is a good list to join and email.
My client is seeing a different version of the website on his computers then what I am seeing on mine. He claims to be deleting the cache. I'm using Safari with the cache disabled via the Develop menu and I see the correct version of the site.
Is it possible that the website is somehow cached by my client's ISP or something along those lines?
Update:
I think I need to describe the problem better:
My client has a web hosting package where he has his domains and email accounts. somedomain.com has it's A record changed to point to Behance's ProSite hosted service.
The problem is that when he goes to somedomain.com he gets the index.html that's sitting in his web server's public_html directory, and not his ProSite. Using the same domain I see the ProSite. He has cleared his cache and tried on a computer at home with the same result. This is what lead me to believe that there is some sort of caching issue somewhere along the line with his ISP(s).
Is there anything I can do about this?
Proxy servers at the ISP or even the client's site might do this. Or even network-compressors in some (mal)configurations.
Depending on the site you might also be seeing actually a different site. e.g. Google redirects to different servers using DNS load balancing.
Yes, you're right. To improve performance and the speed in loading page from the same request modern browser seem to great at caching. I myself have the same problem as well. To resolve this problem You should tag version of your projects whenever you deploy them to production.
Based on the update, the problem was with DNS cache.
DNS can be cached at the following levels:
browser
operation system
router
DNS provider
And each of them has its own way to flush DNS cache. Except DNS provider where the only thing you can is to wait for cache invalidation. Though you can replace your current DNS provider with another one who won't have your domain in his cache. You have all the chances to find such if your domain isn't popular.