OK, after disabling the 44.x.x.x route, Firefox accepts the LoTW certificate for http://encrypted.hamwan.org, and your web pages work.  FYI:  In Internet Explorer (which I tested for you, but don't normally use), there's a long, LONG pause before it asks me to confirm using the LoTW certificate, and then an even longer pause before your web page comes up, that denies access.

After re-enabling the 44.x.x.x route, https://encrypted.hamwan.org still works in Firefox (even after restarting it) -- I hope that's not a bug, because traceroute is showing a direct 44.x.x.x path to it.

However, when I get to my page for adding DNS records, the terminology used fails me, even after 15 years of running BIND with a number of domains and subdomains, and teaching it at the U. Washington:
  1. I know the distinction between a "hostname" and an "interface" on a host, but not in a DNS record.
  2. I know what an "interface" is in a route, but not in a DNS record.
Is that terminology in the RFC?

Somehow I changed the PTR record to be what I want.  However, I'm at a loss as to the difference between creating a "host" (which apparently wants a MAC address, a lat/long, but not an IP address!), and just creating an "A" record.  So, I deleted everything and manually added the "A" record.  As a result, when I click on the "Your hosts" tab, there's nothing, not even a listing header.  I'd gladly use the "Create Host" page, except that I no idea what to do with the "interface" fields.  I have no idea what the "Primary" checkbox is for (more terminology issues).  I know what "primary" and "slave" mean in terms of NS records, but not for a host.

Also, when I do a DNS search for my callsign on your web page, I see all three of my desired DNS records.  However, when I use "DIG", I see:

dig @a.ns.hamwan.net ns1.ae7q.hamwan.net. ae7q.hamwan.net. ns -x 44.24.240.173

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52006
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.ae7q.hamwan.net.           IN      A

;; AUTHORITY SECTION:
ae7q.hamwan.net.        3600    IN      NS      ns1.ae7q.hamwan.net.

;; Query time: 65 msec
;; SERVER: 44.24.244.2#53(44.24.244.2)
;; WHEN: Sun Jun  8 20:03:05 2014
;; MSG SIZE  rcvd: 51

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40908
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ae7q.hamwan.net.               IN      NS

;; AUTHORITY SECTION:
ae7q.hamwan.net.        3600    IN      NS      ns1.ae7q.hamwan.net.

;; Query time: 86 msec
;; SERVER: 44.24.244.2#53(44.24.244.2)
;; WHEN: Sun Jun  8 20:03:05 2014
;; MSG SIZE  rcvd: 51


; <<>> DiG 9.2.4 <<>> @a.ns.hamwan.net ns1.ae7q.hamwan.net. ae7q.hamwan.net. -x 44.24.240.173
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22989
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;173.240.24.44.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
173.240.24.44.in-addr.arpa. 3600 IN     PTR     ns1.ae7q.hamwan.net.

;; Query time: 24 msec
;; SERVER: 44.24.244.2#53(44.24.244.2)
;; WHEN: Sun Jun  8 20:03:05 2014
;; MSG SIZE  rcvd: 77


Note that there is no A record pointing to 44.24.240.173 (the PTR record is correct).   I've spent a couple hours trying to get it to show up in DIG, to no avail.  It didn't show up in DIG even before I deleted the "host" entry.

Also, the query for the NS record doesn't return an ANSWER section;  it just returns an AUTHORITY section (which happens to contain the "answer").  That's not what I see when I query for NS records for subdomains for (as an example) "u.washington.edu".

I'm glad I'm retired and have the time to spend on this ... This is your guys' network, and in a sense, I'm just playing around.  You should run DNS as you want.  However, If someone like me has these issues (I'm a perfectionist), I'll bet others are going to be lost ...

On 2014-06-08 18:18, Tom Hayward wrote:
On Sun, Jun 8, 2014 at 5:24 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:

This requires a specific (and non-current) version of a specific browser (eg, Opera) ?!?!?!?

Dean,

The portal can be accessed from a few different protocols/configurations:

http://portal.hamwan.org/ - plain old HTTP. This can be used to access parts of the portal that do not require authentication, like record listings and the map (e.g., http://portal.hamwan.org/dns/all/ ). We don't suggest logging in here because your username and password would be sent in the clear.

https://portal.hamwan.org/ - HTTP over non-cipher (not encrypted), authenticated SSL. This is a Part-97-friendly way to authenticate with the portal. We have SSL configured to request a Logbook of the World certificate and only negotiate SSL with null ciphers. Most browsers don't allow null ciphers, so they will report an SSL cipher mismatch. I found that Opera 12.16, the most recent version of Opera released for Linux, has an option to allow null ciphers. I wrote up some instructions for this and left the sections for other browsers blank. You or anyone else who wants to experiment is welcome to experiment and come up with some instructions for other browsers.

http://encrypted.hamwan.org/ - redirects to https://encrypted.hamwan.org/

https://encrypted.hamwan.org/ - HTTP over encrypted, authenticated SSL. This is configured for standard, encrypted SSL, so it is NOT allowed over Part 97, but should work with normal browser settings.

The content is the same at all of these addresses; it's just the protocols that differ.

By the way, the SSL configuration may not be compatible with Internet Explorer; I never tested it. I seem to recall something about Internet Explorer not liking optional SSL authentication (as opposed to forced or disabled). Firefox, Chrome, Safari, and Opera are tested and working.

If you've done all this and it's still asking you to authenticate, there may be a bug in my code that pulls your callsign out of the LoTW certificate.

Tom KD7LXL