I've recently found something that questions everything I thought I knew about TLS.
This website https://int.lyve-lyon.alpha.grandlyon.com is secured with TLS but the certificate is actually issued to rec.lyve-lyon.alpha.grandlyon.com.
How can the server submit a certificate issued for a different host, and how can the browser not throw a TLS error? It looks like the certificate behaves like a wildcard one and I cannot understand why.
Subject Alternative Name (SAN) is an extension to X.509 that allows
various values to be associated with a security certificate using a
subjectAltName field. These values are called Subject Alternative
Names (SANs). Names include:
Email addresses
IP addresses
URIs
DNS names (this is usually also provided as the Common Name RDN within the Subject field of the main certificate.)
directory names (alternative Distinguished Names to that given in the Subject)
other names, given as a General Name: a registered[3] object identifier followed by a value
from https://en.wikipedia.org/wiki/Subject_Alternative_Name
Related
When testing under Android P, found a problem with the certificate. The UE was giving an error for the hostname resolution.
As per Adroid P:
RFC 2818 describes two methods to match a domain name against a certificate - using the available names within the subjectAlternativeName extension, or, in the absence of a SAN extension, falling back to the commonName.
The fallback to the commonName was deprecated in RFC 2818 (published in 2000), but support still remains in a number of TLS clients, often incorrectly.
the existing .cer has:
DirName:/C=DE/ST=xxx/L=xxx 81673/O=my company wireless products /OU=Test/CN=prod.comp.com/emailAddress=xxx#comp.com
How to add subjectAlternativeName configured to the existing cerficate?
Certificate is digitally signed and tamper-evident. If you modify any bit of the certificate, the signature will be broken and certificate will become invalid.
The only way to get new values there is to acquire new certificate by using same procedures used to get current certificate.
I am having Postfix server configured for domain. From last few days my mails are marking as spam in gmail. I have already configured DKIM,SPF and DMARC for this domain. I have checked mail source and getting
"Authentication-Results: mydomain; dmarc=fail header.from=mydomain"
I have checked all the support docs but didn`t find anything.
Could you provide full sample headers or run a classification test with a third party?
Often, the TXT records aren't correctly created with the proper name style or have a syntax error causing the mail server parser to fail. Since DMARC fails the issue can be in either SPF or DKIM. In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment.
Generally speaking, its really hard to help without proper details. Kindly always provide DNS and configuration samples.
I came across a few URLs which also render with or without a dot/period after .com, while some do not.
For example:
www.example.com.
Should the URL render normally if a dot/period is added after .com or should it go to a 404 page?
As said in comment this great resource, solves many of your queries, including a portion below specific to your query:
Fully-Qualified Domain Names
When I double-click a Bonjour (DNS-SD) Name in a web browser like Safari, the resulting URL has a hostname with a dot at the end. Is this a bug?
No, the dot at the end is correct.
You can try it here. Try adding a dot at the end of www.dns-sd.org, as shown in the subtitle at the top of this page, and you should still get the same page.
It's a little-known fact, but fully-qualified (unambiguous) DNS domain names have a dot at the end. People running DNS servers usually know this (if you miss the trailing dots out, your DNS configuration is unlikely to work) but the general public usually doesn't. A domain name that doesn't have a dot at the end is not fully-qualified and is potentially ambiguous. This was documented in the DNS specification, RFC 1034, way back in 1987:
Since a complete domain name ends with the root label, this leads to a
printed form which ends in a dot. We use this property to distinguish between:
a character string which represents a complete domain name
(often called "absolute"). For example, poneria.ISI.EDU.
a character string that represents the starting labels of a
domain name which is incomplete, and should be completed by
local software using knowledge of the local domain (often
called "relative"). For example, "poneria" used in the
ISI.EDU domain.
How this affects web browsing
The people defining the HTTP protocol understood this issue, and RFC 1738 specifies clearly that the part of a URL is supposed to contain a fully qualified domain name:
3.1. Common Internet Scheme Syntax
//<user>:<password>#<host>:<port>/<url-path>
host
The fully qualified domain name of a network host
Unfortunately, the people implementing web browser clients appeared not to understand what this meant. When you access a web site, the value most web browsers put in the "Host:" field is what the user typed, not what the computer actually ended up using, after applying the DNS user's searchlist to constuct a fully-qualified name from the partial name. For example, here are three different ways the user may refer to the host "www.example.com."
www.example.com. — Absolute domain name
www.example.com — Relative domain name, which, after applying the "." that's always implicitly in everyone's DNS searchlist, becomes www.example.com.
www with "example.com" in DNS searchlist — user types "www" and gets
www.example.com.
When sending the Host: parameter to the web server, the web browser client puts in what the user typed (www.example.com., www.example.com, or www) instead of what the client ended up actually looking up in DNS (www.example.com. in all three cases). Unfortunately the Apache web server (at least in some versions) doesn't recognise that all those three names are just three different ways of referring to the same host.
If you're a web site administrator setting up a web site using Apache "VirtualHost" directives or similar, you need to have a ServerAlias line listing all the things the user might type to get to that web site (typically the first label, the whole name without a trailing dot, and the whole name with a trailing dot, as shown in the example above).
See: http://www.dns-sd.org/trailingdotsindomainnames.html
And the old RFC it links to: http://www.ietf.org/rfc/rfc1034.txt
Truly fully qualified domain names have a period after the TLD, but unless you're managing a DNS server you almost never come across them. It is however something you might want to consider if you were for instance writing an HTTP server varying on hostname.
A period at the end of a hostname is an indicator that the resolver should not attempt to use its search domains in order to resolve the hostname if the given name does not resolve. That is, if the resolver has a search domain of "lan", if you attempt to look up "web" it would first try resolving "web" followed by "web.lan", but with "web." it would only try "web".
As for the server, it never sees the URL, only the hostname and path (as separate entities), and there is no reason for it to complain if the Host header includes the period (although there is also no reason for the client to include it).
I want to set OpenDMARC to support multiple domains and only show the header for the domain sending the email.
Adding more than one AuthservID doesn't do it. the header shows as
Authentication-Results: domain1.com; dmarc=none header.from=domain2.com
You are misunderstanding the syntax of the Authentication-Results: header.
The first field, in your case domain1.com, is essentially a site ID for the service that performed authentication verification. Different sites do this slightly differently, but it is not intended to correlate to the recipient domain. It is intended to identify who performed authentication validation. Yahoo, for example, puts specific hostnames in that field, such as mta1315.mail.gq1.yahoo.com. Google and Hotmail both just use more generic mx.google.com and hotmail.com identifiers respectively.
Refer to section 2.4 of RFC 7001 "Message Header Field for Indicating Message Authentication Status" (https://www.rfc-editor.org/rfc/rfc7001#page-13) for full details.
Only the SPF and DKIM identifiers - domain2.com in your example above - or each instance of agari.com in my example below:
Authentication-Results: mx.google.com; spf=pass (google.com: domain of chris#agari.com designates 2607:f8b0:400e:c03::22b as permitted sender) smtp.mail=chris#agari.com; dkim=pass header.i=#agari.com; dmarc=pass (p=REJECT dis=NONE) header.from=agari.com
relate to the recipient domain. Note that because our email is hosted with google apps, the identifier is mx.google.com, telling me who validated email authentication.
I would recommend configuring AuthservID to a value that represents either the machine that performed authentication, or perhaps an organizational name or identifier if appropriate for your site.
I have the following requirement to map many domains to a single site instance for my web application, and I'm wondering if this is solvable using a single SSL wildcard certificate in IIS 7, or whether I need two wildcard cerfiticates. Here's my current plan:
Certificate #1 - *.mydomain.com
https://customer1.mydomain.com
https://customer2.mydomain.com
https://customer2.mydomain.com
etc...
Certificate #2 - admin.*.mydomain.com
https://admin.customer1.mydomain.com
https://admin.customer2.mydomain.com
https://admin.customer3.mydomain.com
etc...
My intentions are the following:
A single IP address that all of the above domains map to.
Can this be accomplished without the second certificate? I was told that I must have two by both Thawte and Godaddy.
The website is really the same site instance for all clients, but a different color scheme and logos will be displayed based on the URL. (hence multiple domain names)
I do not want to have to replace the certificate each time I add a new customer, hence the wildcard certificate.
I want to automatically redirect any request that comes in as http:// or blank to any of the above URLs to its https:// counterpart. For example, http://customer1.mydomain.com would automatically redirect the user to https://customer1.mydomain.com. I am currently doing this with a regular certificate, but since we're growing, I want to switch to wildcard. Is this still possible with the URL Rewrite IIS Snap-In?
I'm curious if anything I'm doing here is bad practice or if there is a better approach.
Thanks
In your example, certificate #2 isn't possible. However, certificate #1 is. To use a single wildcard, you might be better off using certificate #1, and then using customer1.mydomain.com/admin for the admin portion. Or admin.mydomain.com/customer1. Then you could configure your DNS, http redirects, and context switching to get the client to right portion of your app from the admin.customer1.mydomain.com.
Another option would be to use names like customer1.mydomain.com and customer1admin.mydomain.com. That would all fall under your certificate #1 wildcard and get a similar outcome to your plan perhaps.
As of this posting, this is not possible with a wildcard certificate.