Hi,

Thanks for the reply.

For DNS use case,

" Operator may make certificates only once in a while (as they cost), and at that point it is not certain that all IP addresses are known. They likely might now only know the current literal address, but the numeric address can change in the lifetime of the certificate

Changing /etc/hosts is not possible, as this configuration is not supported for operators. "

Still we feel configuration is a good thing, i.e., if one explicitly wants to allow a connection despite of warnings (i.e., has analysed the warning to be a false positive), that should still be acceptable, and not unilaterally bad. Also, one needs to be able to distinguish between =E2=80=9Cnormal=E2=80=9D network (open for everyone), and an operat= or-internal network: requirements for these two are different, and if one library is to serve both, it should be able to handle (=3Dbeing configurable) both use cases.

System configuration setup is anyway also done by a human, so if someone wants explicitly disable some checks for automated clients, it is logically similar to a human pressing some =E2=80=9Cacknowledge=E2=80=9D= button.

And i don't think the browsers are going to remove it, at most they may move this option to settings. I think nobody wants a monolithic browser that cannot be tailored for user needs, which anyway cannot be anticipated by the browser maker. Whether it is interactive or configuration based does not matter as long as the configuration is there somehow. And the same logic applies also for LDAP ;)

But then openLDAP or openSSL is already providing options to ignore some of the certificate errors, for example, i can set SSL verify call back function via LDAP options to ignore certificate CRL errors and continue the connection. So i still wonder why it is not possible in this case and feel it has to be user configurable.

Regards, Sudhir, NOKIA