Hello, Piotr. Thanks.
Well, we tested this with fred-client at the server itself. I changed manually the handle and all worked (not necessarily for them). Of course, I suggested to them they change the handle only to all-uppercase and we will see.
BTW, our test server for them is using FRED 2.58 (similar to our production server) . We will see on Monday how things go.
Anyways, I'm forwarding this answer to them.
Best regards
Mario Guerra - NIC-CR
De: Piotr Przybyl <piotr@przybyl.org>
Enviado: viernes, 5 de julio de 2024 09:02
Para: A mailing list for users and developers of FRED registry system <fred-users@lists.nic.cz>
Cc: Ricardo Samper Jimenez <rsamper@nic.cr>
Asunto: Re: A curious behaviour for a FRED client
Hello Mario!
Is it so that the first request and response are working okay, and the subsequent ones fail perhaps when using a Java client?
I can't remember the details now, and I have no access to the sources and deployment anymore.
The symptom was: the first exchange was okay (so login), the next one failed. It was caused by Java 7 onwards going with CBC by default, while it wasn't supported by FRED or Apache HTTP server that time.
So years ago the solution was to disable CBC in the client.
I don't know if that's that, but maybe it's worth trying? Something with `System.setProperty()` would do the trick.
Thank you
Piotr
Got it and it is quite curious. The problem SEEMS to happen if the registrar handle has lowercase letter(s). I'm testing this more thoroughly.
Best regards.
Mario Guerra - NIC-CR
Hello.
One of our clients, who wish to connect to our FRED server is having problems for managing his connection. Also, I can reproduce their situation.
Most of our registrars use either the fred-client Python-based script, or the Python API. And they can manage all their operations without problems.
In their case, they connect in a completely different way. They use a Java-based client, and also they generated THEIR csr file. It was sent to us, along their key, in a zip file). The csr file was appopiately signed, put in the proper place at /usr/share/fred-client/ssl,
so the certificate and key are present.
And here is what is odd. They can properly login (and us too using fred-client testing that). But if you try to manage any objects at the creation, a
Command failed is issued. This happens with their Java-based client and also with fred-client, testing their configuration, certificate and all.
And the odd thing is that any other client manages every thing appropiately.
Here is the fred-client.conf relevant part:
### Connection settings
[connect]
# Path to the directory with certificates
dir = /usr/share/fred-client/ssl
# Server name
host = 127.0.0.1
# Server port (default: 700)
port = 700
# File path of the certificate
ssl_cert = %(dir)s/<our client>.crt
# File path of the private key
ssl_key = %(dir)s/<their key>.pem
# Login username and password
username = <their username>
password = <their password>
As I said the login is perfect but not the object management
Any hints?
The certificate was signed using their key, but our CA.
Best regards
Mario Guerra - NIC-CR
_______________________________________________
fred-users mailing list --
fred-users@lists.nic.cz
To unsubscribe send an email to
fred-users-leave@lists.nic.cz