Sorry if duplicate, poked around but couldn't find anything.
I have 4 URLs that I'd like to use the same certificate for.
dev.myapp
qa.myapp
dr.myapp
myapp
I got a certificate for the wildcard *myapp. I am testing this in dev, however this doesn't seem to work, AWS has told me that the wildcard should be *.myapp
Couple questions on this.
1) Can I change the existing certificate to use the wildcard *.myapp? But will this work in my prod "myapp" env?
2) Is the right way to do this to have two wildcards *myapp and *.myapp? The same question applies if I can ADD a wildcard to the existing certificate.
You can't change an issued certificate. No one can; if they could the whole system would be insecure.
What you maybe can do is have the CA issue a new and (somewhat) different cert to replace the problematic one. Many probably most CAs have provisions for doing this without repeating the identity and/or domain 'ownership' proofs and without additional fee (if any), but details vary depending on the CA and sometimes the features you purchased, which you have carefully not identified, making a specific answer impossible.
Also I assume the names you gave are falsified, because myapp is not a TLD, if it were you would not control it, and no-one at all can ever control a suffix of TLDs. Assuming your actual names are something more like:
1 example.com
2 dev.example.com
3 qa.example.com
4 dr.example.com
and you are the 'owner' of (or at least control) example.com, then a wildcard cert *.example.com matches 2-4 but not 1. There is no wildcard that matches all four.
However, SSL/TLS certificates (including HTTPS) are not limited to a single name: they support the SubjectAlternativeNames extension which can have multiple names. This is commonly abbreviated SAN, and also called 'multi-domain' or in the Microsoft world 'UCC'. In past decades CAs often charged extra for this, but in recent years it has become commonly included in the basic service. For example if you purchase/request a cert for www.example.com many CAs nowadays will actually give you SAN=www.example.com,example.com automatically. (To be exact, SAN=dnsName:www.example.com,dnsName:example.com because SAN can also do some other things that aren't relevant to SSL/TLS/HTTPS.)
For your case, SAN=example.com,*.example.com would accomplish what you want. So would SAN=example.com,dev.example.com,qa.example.com,dr.example.com, although that would 'expose' your subdomain names to anyone who monitors and/or starts a connection to your server. Check with your CA to see if they will issue you a new cert in one of these forms.
Related
Can I use the .ag top level domain (TLD) on Heroku? Where can I find information on Heroku TLD limits, if there are any?
Context: I've been looking into the world of custom TLDs and found that non-standard ones aren't available for sale as widely as a typical .com is, even for ones assigned to identify specific countries like .ag is. This makes me extra cautious about moving forward with claiming the one I want. It's also more expensive than a .com, so "just wait and see" isn't the ideal solution for figuring this out. This TLD is especially convenient because I'd like to use it for a short links app, and the domain name I want to create is short and will have a clear association with my brand.
Research: I read Heroku's documentation on adding domain names. All of the examples are .com. There's also some Heroku documentation on browser security and cookies that discusses TLDs, including some that identify a country. I got the impression from the two sources that I can claim any domain that's not already claimed, but I'm still not sure about if there are any technical concerns I should be aware of beforehand.
I should also mention, I didn't see any error when I added the domain to Heroku (before purchasing it).
on an azure webapp i am trying to add custom bindings like this (the names are examples):
træmand.dk
and the common equivalent replacing the æ with ae
traemand.dk
both versions are correctly set up in DNS (not azure) with asuid, and validating both in azure before adding is all good.
BUT i can only add ONE of them. If one is added, then the next one will try, but say "Failed to add hostname træmand.dk. The host name is already assigned to another azure website: (says same website)"
it does not matter which one is added first. The second one will fail.
I have tried using puny codes. But it will not verify the asuid with these.
What to do?
We ended up creating a redirection app in a different region that receives one of the versions and redirects to the one chosen to be the official one.
It's a cumbersome workaround, but there seems no way around the "intelligent-same-name"-function. Luckily different regions don't speak with each other, so the alternatives could be configured there.
I want to point mysite.com to myapplication.herokuapp.com
Searched hard and was speaking with hostgator support, they say - it is impossible, heroku is not supporting A records and CNAME are not able to point from naked domain.
You can do it with A records…but Heroku really doesn't want you to, and with some good reasons. One thing you can do is run
$ host myapplication.herokuapp.com
and find out what IP that points to, and then create an A record pointing to that IP. But this is very brittle: if Heroku changes that IP, then your domain won't work until you update your A record. This method will probably break at some point, so you shouldn't do it, even though you technically can.
Luckily, there are solutions. Heroku outlines them in their documentation for custom domains, particularly in their documentation for root domains. The best one is to use a DNS provider that supports "ANAME" or "ALIAS" records, which are like CNAME records in that they point to another domain (rather than IP), but can be used for root domains. DNS doesn't natively have such support, so these are a bit of a hack, and are only supported by a few providers, namely DNSimple and DNS Made Easy. This solution is the best, most robust solution.
I use DNSimple and have found them to be very reliable and excellent to work with.
This question was already asked and answered here: https://stackoverflow.com/a/16041655/758334
I can vouch for dnsimple. There was a number of reasons why I switched to them, but their support for ALIAS records to make pointing the apex domain to hosted cloud apps was a big one for me.
Can anyone recommend me an overview about certificate management? I'm a big "learn from Wikipedia" type of guy but the relevant data there is general information on public-key cryptography, and I'm looking to map that to practical knowledge about how certs are used (web browsing, exchange of business messages, etc.)
I don't need super-detailed information at this point, but I'm looking for a general overview about things like:
File types one would expect to see, and what kind of information they contain
How certs are organized and "chained"
What certs are used for - I generally understand the basics like signing and encryption, but I know they're used for a lot more than that. For example, how are certs used in web browsing or (to validate a site), or HTTPS (to secure transmission)?
I'm a Windows guy, so information about the way certs are organized and used in Windows (the cert store) would be helpful as well.
Thanks!
I'm doing some funky authentication work (and yes, I know, open-id is awesome, but then again my open-id doesn't work right at this moment!).
Stumbling across Windows CardSpace I was wondering if anyone has used this in a real product-system. If you have used it, what were the pros and cons for you? And how can i use it in my open-id?
Umm no you don't; you can accept information cards on a web site using a cheap and cheerful certificate (but not self signed) or no certificate at all.
And yes, I've used it as part of a production system which grew out of a proof of concept I did at Microsoft.
Cons: If you don't have an EV SSL certificate you get warnings. The code for parsing a card is incomplete at best (you have to hack it around for no-SSL), you have to explain to users what one is.
Pros: Well that's more interesting; I was using managed cards and issuing them and then having 3rd parties use those to check claims; but for self issued cards; well, it's stronger than username password and doesn't have the same vulnerabilities OpenID has.