Can I use Let's Encrypt to generate SSL Certificate even if I don't own the domain name? The scenario is I have a site that lets user create their own sort of page inside my site which would be a subdomain under my main domain. Now, there's a feature that they can use their own domain name (using a different provider) that will point to the created page on my site so they can use any domain name that they want.
Will I still be able to provide SSL using Let's Encrypt to my user? Note: I'm new at this thing so I am not sure if I am asking the correct question, but I am asking as how I understand it right now.
Yes.
The validation occurs based on HTTP file retrieval or via DNS through TXT records.
I built Greenlock to be able to handle exactly that kind of use case. It will currently work for the scenario that you suggest and I plan to implement more DynDNS support in the future.
Related
I'm building an application that has a core hub, say it's called musictickets.com
We'll provide a subdomain (bandname1.musictickets.com) to bands on which only their content will display, which they can mask using a CNAME record to be part of their domain - so tickets.bandname1.com
There would be multiple bands using the platform so you'll end up with pages at
tickets.bandname1.com
tickets.bandname2.com
etc.
I'd like a user who registers at tickets.bandname1.com to be automatically logged in on every site that uses the service, including the parent, musictickets.com . They should be able to register/login using OAuth or directly via form based authentication.
I'm looking at SAML (specifically https://github.com/aacotroneo/laravel-saml2) as one option, but want to throw this out to the wider community for comment.
I've also looked at using token based SSO as described here (single sign on (sso) laravel) and running an auth server (which I may do in any case). Alternatively, I've looked at using iframes to provide the functionality which feels quick but dirty.
As I understand it, I wouldn't be able to use cookies (for an API key for instance) because whilst all of the content will be displayed via a subdomain, the CNAME would make it a different domain.
Does anyone have any thoughts on the best strategy?
I have 2 Asp.Net Core 2.2 applications and I want to share session between them. I've set up session in a SQL database and both connect ok. They are on different sub domains. I understand that I can set the Cookie.Domain the startup file, which would solve the problem at a basic level, so each application would create the cookie such that it can be accessed. e.g.
Domain 1. "www.website.com"
Domain 2. "dashboard.website.com"
At present these sites can't access each others session cookie.
If I set the domain cookie to ".website.com", both should be able to access this.
The problem is that we have multiple domains that use this website, so it could be:
www.domain1.com
dashboard.domain1.com
www.domain2.com
dashboard.domain2.com
www.domain3.com
dashboard.domain3.com
I need to be able to inject the current host name into the startup cookie domain, in order to have it dynamically set, depending on the domain of the active website.
Is this at all possible?
Just to clarify, www.domain1.com does not need to be able to access www.domain2.com.
Only the www. and dashboard. variations of each domain need to be able to connect to each other.
Thanks in advance,
David
To share sessions across applications, you need only follow the directions in the docs. It basically boils down to two things:
You need to persist the data protection keys to a common store that all the apps can access. A UNC path will do, or you can even use something like Azure Key Vault.
You need to set a common application name. Data protection values are segregated by application by default. Setting a custom name, which is then used across all the apps allows them to all access the same set of data.
As far as setting the cookie domain goes. There's no good way to do this by convention. The actual domain name is only available in the context of the request pipeline, which is not available to you in something like Startup (there's no request). Even if you could, it's not reliable anyways. In situations where you have a reverse proxy or, importantly , when hosting in containers, the domain will be localhost, since the actual domain isn't applied directly to the app.
Long and short, your best bet is to use configuration. You can, for example, have environment-specific JSON files like appsettings.Domain1.json, appsettings.Domain2.json, etc. Inside each, you can add a something like:
{
"CookieDomain": ".domain1.com"
}
Then, when you deploy, you set the environment to the appropriate domain, and that config file will be used. In Startup, you'd just do:
services.ConfigureApplicationCookie(o => {
o.Cookie.Domain = Configuration["CookieDomain"];
});
I try to use composer to develop a block-chain web app.
I write the ".acl" file to implement access control, and I also issued different IDs to different participant, then I start the REST server.
The next thing I want to ask is, how can the REST server identify my identity?
Just like, one kind of participant is named "trader", I specify "trader" cannot access function "A" in chaincode, but REST server generate the API of "A", then I write a simple html file and send a POST request to localhost:3000, I can invoke this function directly. I even don't know I access this interface by what kind of identity.
I am confused about this, can some one help me?
Remember how you started the REST server? You had to specify a business network card, and likely it was the card for the admin with all reading and writing rights. Also most likely, you disabled authentication with passport.
With these two elements, of course you can always do anything just by calling any available API function.
You can refer to the passport authentication instructions for composer-rest-server to implement your authentication scheme.
You should code the rules for what is allowed for certain groups (such as "patients", "doctors", "payers") in the ACL permission files. Refer to the section "Granting Network Access Control" in https://hyperledger.github.io/composer/latest/reference/acl_language, which contains some pretty similar examples.
Illicit API calls would then simply fail if attempted by the wrong entity.
Letsencrypt domain validation requires folder with dot in it like .well-known/acme-challenge but Parse.com hosting's public folder deploy ignores folders with name start with dot char.
Dot character seem to be mandatory for the ACME verification.
Parse.com team should consider supporting folder name with dot to support Letsencrypt. Time being I wish to know any other alternative solution.
This is a odd workaround but might work if Parse.com allows you to issue redirects
Let´s Encrypt client will follow http redirects so you can redirect it to another place which contains the .well-known challenge. You might have to run it in standalone and put challenge by hand at the other place but it will work. You can try to redirect it to S3 bucket on Amazon AWS for instance or to your own PC running a miniserver.
But I don´t know Parse.com and if they support you to configure http redirects.
good luck.
I need to implement a way to integrate my code so that I could add and remove domain aliases for a single site in WebsitePanel.
I have tried to check WebsitePanel's API, but it seems to be very limited and doesn't allow any management of sites and their domains.
Any ideas how I could do it in some other way?
I was thinking about adding domain alias directly to the site configured in the IIS (7), but I might need to add mail accounts and manage the DNS of the domain alias in the future so it doesn't seem like a good idea.
I have the same issue: I'm trying the 'wget' approach. Login can be done using Default.aspx?pid=Login&user=USER&password=PWD
Then go to the Domain area for each client, and post some data (seems to be the same for each client/domain, can be easily read from the form/input id), to get to the DNS management web.
It's way late, and it's not just "do this", but hey, it is a starting point until something better appears.