Something like this would work with HAproxy:
https://www.haproxy.com/blog/ssl-client-certificate-information-in-http-headers-and-logs/
Best,
On 31 Mar 2022, at 11:14, Mario Loffredo wrote:
Hi Francisco,
Maybe we are complicating a bit (just to be polite) something that
would be very easy if the server started every EPP session only
after a successful Login.
Anyway, just for curiosity, can you provide me with an example for
NGINX?
It doesn't sound so simple according to this post
<https://stackoverflow.com/questions/64810700/reading-client-certificate-details-with-nginx>
Best,
Mario
Il 31/03/2022 19:36, Francisco Obispo ha scritto:
In a scenario where a proxy/load balancer is terminating the TLS
connection, it will most likely need to extract the certificate
information, and encode it into a HTTP header, so that the backend
could later tie the |clID| with the certificate in a way (i.e.:
|cn|).
That's what I would do, to at least guarantee that the client
certificate correspond to the |clID|.
Best,
On 31 Mar 2022, at 9:56, Mario Loffredo wrote:
Hi Patrick,
thanks for your interest.
Il 31/03/2022 17:54, Patrick Mevzek ha scritto:
On Thu, Mar 31, 2022, at 10:36, Mario Loffredo wrote:
Starting an HTTP session when receiving an EPP command
other than the
Login command is in .it experience (but I can speak on
behalf of .pl
too) very inefficient because you can't immediately lock
the HTTP
session to the Registrar.
I disagree.
If the transport is HTTPS (and not just HTTP), the server can
request
the client to send a certificate, exactly as for EPP over
TLS.
In such case, for *any* HTTP request coming to the server,
the
server
theoretically already knows to which client this pertains as
it can
consult the certificate given.
It can be considered a weak or partial authentication, until
the EPP login
is successfully executed.
Are you talking about a signle server or a load balancing
architecture where a proxy routes the requents to a pool of
backend servers?
In addition, it is quite simple to do at socket level. It seems
to
me much more complicated at the servlet level.
Mario
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
