[EMAIL PROTECTED] wrote:
On Jun 9, 2:55 pm, Michael Ströder [EMAIL PROTECTED] wrote:
I really wonder what makes a host name an unqualified hostname?
One workable definition is a host name without a dot . (ignoring any
trailing dots).
This would exclude issuing certs for a top-level
Jean-Marc Desperrier wrote:
Michael Ströder wrote:
[...]
RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching
rules which was obsoleted by RFC 3280 which was recently obsoleted by
RFC 5280. RFC 5280 references Preferred name syntax in RFC 1034.
Glancing over these documents
Michael Ströder wrote:
[...]
RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching
rules which was obsoleted by RFC 3280 which was recently obsoleted by
RFC 5280. RFC 5280 references Preferred name syntax in RFC 1034.
Glancing over these documents I found no provision that
Eddy Nigg (StartCom Ltd.) wrote:
For internal networks, internally assigned domain names should be used,
like NETWORK = intern.domain.com
Thinking further about this whole stuff:
I consider the hostname checking to be a very important validation of
whether the browser really connects to a
On Sun, Jun 8, 2008 at 6:54 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote:
I recently encountered a web site with a certificate that chained through
two intermediate CAs to one of Mozilla's trusted roots.
This cert's Subject Alt Name (SAN) extension included:
- 43 wildcard domain names (e.g.
Wan-Teh Chang wrote:
There is a bug on certs containing unqualified host names:
https://bugzilla.mozilla.org/show_bug.cgi?id=401317
I really wonder what makes a host name an unqualified hostname?
No doubt that https://www/ looks like a valid example to us humans. But
how about https://com/
6 matches
Mail list logo
