There is also a subtlety about whether machines can even tell whether they are "on" a specific network or not. The layering model in the IP protocol stack has mostly made it so that network access and identity is either unauthenticated, or not transparent to higher layers (like the browser).
For a corporate application you might want to be able to say either
be more trusting when I'm on this particular WPA2 wireless LAN or this particular VPN, compared to other times
or
never connect to the Internet at all, except via this particular WPA2 wireless LAN or this particular VPN
(I think Microsoft Internet Explorer even has a setting that trusts LAN machines more for some purposes than non-LAN machines, although I don't remember exactly how that works.)
But this is hard to guarantee in IP not just because we don't necessarily have the right APIs for it in our software stacks, but also because an attacker might be able to attack the routing on a LAN in order to hijack another machine's connections, or might be able to proxy whatever kind of authentication is happening in order to make it appear that a network connection should be treated as a trusted one when it's not. In the corporate network case, the simplest version of this attack would be if the attacker controls one legitimate client machine on a LAN and wants to use that access to attack another legitimate client machine's access to server resources.
Basically, I don't think the IP networking technology has a good way to connote "this network is trusted", so trust relationships have to be conveyed typically at the application layer. Which is more work for a network administrator, to be sure.
Without going into too much detail, yes, we are (now were) considering using a global CA to replace the internal corporate one(s). We are motivated to do this because in the organisation there is much segregation of technology areas and the group responsible for CA management cause our group much difficulty. So after repeated attempts to improve things we happened on the idea of removing that group from consideration by using a reliable CA source and automating things so the entire workload for managing certificates goes away. We have thousands of servers and and many staff. Our staff are so inured to certificate errors in browsers that they click through it as a matter of course. We are trying to fix that by removing the errors completely. The use of shortnames is extremely widespread. In the web services for staff use there are hundreds of pages with URLs of shortnames embedded. We are dealing with a long and complex history of technology.
Perhaps we'll consider setting up our own internal CA that we can manage and automate that way.
Thank you for all the assistance. I am very impressed by and grateful for the many contributions to my question in this forum.
That is a bad place to be and I'm not sure if that habit can be broken.
Here SED (find and replace) may help clean up the previous mess.
[they should assign the CA crew to do that job - LOL]
But a cleanup won't teach anyone to stop making messes.
Such change has to enforced at a much higher OSI layer [company policy].
[Also, when self-referencing links, it is better to not use any name at all - probably the least of the uses]
By the way, although this might cause greater social challenges in the workplace, you can potentially prevent them from doing this by setting HSTS on these services
In common modern browser implementations, that removes the ability for users to bypass the certificate warning if there's a subsequent certificate error following a recent successful connection. This can be set purely on the server side, without having to change anything on the client side. I just thought I'd mention that in case you would prefer to try to block/undermine/not reinforce this habit on your users' part.
I only know how for Chrome. But basically when you're in the tab with the HSTS block message, type "thisisunsafe" (no quotes) and it will enable the buttons to click through. More info here.
According to the stackoverflow thread, the process is likely to change over time as the procedure becomes widely known because the devs don't want it being just another thing everyone knows how to do.
tell me! 