| 1 |
On Wednesday 24 December 2008, Peter Humphrey wrote: |
| 2 |
> On Wednesday 24 December 2008 00:03:46 Mick wrote: |
| 3 |
> > If you are using SSL certificates you must set up the correct domain |
| 4 |
> > name, with regards to what the client machines see on the intranet/LAN. |
| 5 |
> > Clearly the IP address is not a FQDN and the certificate check fails. |
| 6 |
> > So, you want your common name (CN = serv.ethnet or whatever) to be the |
| 7 |
> > same with the name that your server is seen by the client in the LAN and |
| 8 |
> > this may involve setting up your router to resolve serv.ethnet to |
| 9 |
> > 192.168.2.2, or adding an entry in your client's /etc/hosts file to this |
| 10 |
> > effect. |
| 11 |
> |
| 12 |
> I'm not using SSL certificates, or not as far as I know. |
| 13 |
|
| 14 |
Well, if you are getting security error messages about security certificates |
| 15 |
as per your previous email, I would think that you have inadvertently perhaps |
| 16 |
configured SSL connections to your CUPS server? |
| 17 |
|
| 18 |
> Every host on the |
| 19 |
> LAN has serv.ethnet in its hosts file, and dnsmasq on the gateway also |
| 20 |
> knows about it - of course. The problem is not in name resolving. Both the |
| 21 |
> cups server and the box running the Web browser are on the same LAN |
| 22 |
> segment. I've just checked all the boxes' hosts files and they're all |
| 23 |
> correct. |
| 24 |
|
| 25 |
It could still be a machine naming issue if you are pointing your client to |
| 26 |
e.g. http://192.168.2.2:631 instead of http://serv.ethnet:631 - which is what |
| 27 |
I suspect the SSL certificate's CN record shows. Either way - if you disable |
| 28 |
authentication with SSL this problem will go away. |
| 29 |
-- |
| 30 |
Regards, |
| 31 |
Mick |
Archives