4 Jul
2024
4 Jul
'24
10:54 p.m.
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
5 Jul
5 Jul
4:41 p.m.
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
________________________________
De: Mario Guerra <mguerra(a)nic.cr>
Enviado: jueves, 4 de julio de 2024 14:54
Para: fred-users(a)lists.nic.cz <fred-users(a)lists.nic.cz>
Cc: Ricardo Samper Jimenez <rsamper(a)nic.cr>
Asunto: A curious behaviour for a FRED client
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
5:02 p.m.
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
On Fri, 5 Jul 2024 at 16:42, Mario Guerra <mguerra(a)nic.cr> wrote:
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
------------------------------
*De:* Mario Guerra <mguerra(a)nic.cr>
*Enviado:* jueves, 4 de julio de 2024 14:54
*Para:* fred-users(a)lists.nic.cz <fred-users(a)lists.nic.cz>
*Cc:* Ricardo Samper Jimenez <rsamper(a)nic.cr>
*Asunto:* A curious behaviour for a FRED client
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(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
5:13 p.m.
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(a)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(a)lists.nic.cz>
Cc: Ricardo Samper Jimenez <rsamper(a)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
On Fri, 5 Jul 2024 at 16:42, Mario Guerra
<mguerra@nic.cr<mailto:mguerra@nic.cr>> wrote:
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
________________________________
De: Mario Guerra <mguerra@nic.cr<mailto:mguerra@nic.cr>>
Enviado: jueves, 4 de julio de 2024 14:54
Para: fred-users@lists.nic.cz<mailto:fred-users@lists.nic.cz>
<fred-users@lists.nic.cz<mailto:fred-users@lists.nic.cz>>
Cc: Ricardo Samper Jimenez <rsamper@nic.cr<mailto:rsamper@nic.cr>>
Asunto: A curious behaviour for a FRED client
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<mailto:fred-users@lists.nic.cz>
To unsubscribe send an email to
fred-users-leave@lists.nic.cz<mailto:fred-users-leave@lists.nic.cz>
16 Jul
16 Jul
1:39 p.m.
Hello Mario.
Thank you for letting us know about an issue related to lowercase chars
in registrar's HANDLE. We can reproduce it. The reason of this behavior
is the fact FRED uses UPPERCASE handles (except of the fqdn) including
registrar's one. Clients (fred-admin and FERDA) ensure the HANDLE is
stored to the fred DB in UPPERCASE.
We strongly suggest to use UPPERCASE registrar HANDLE. Here is a DB
constraint that should prevent non-standard input. We must warn you,
however, that you should definitely NOT run this constraint during
traffic. Ideally, we recommend scheduling a downtime and running this
during that downtime. We also recommend that you create a backup of the
database before running it.
Let us know how it went, and do not hesitate to contact us in case of
any problems.
Normalize data that does not fit the new constraint:
```
UPDATE registrar
SET handle = TRIM(UPPER(handle))
WHERE handle != TRIM(UPPER(handle));
```
After data normalization it is possible to create new constraint:
```
ALTER TABLE registrar
DROP CONSTRAINT registrar_handle_check,
ADD CONSTRAINT registrar_handle_check CHECK(TRIM(UPPER(handle))
= handle AND handle <> '');
```
Best regards
--
Jiří Morariu
System administrator
---------------------------------
CZ.NIC, z.s.p.o.
Milešovská 5
130 00 Praha 3
e-mail: jiri.morariu(a)nic.cz
web: https://www.nic.cz/
---------------------------------
4:11 p.m.
Hello and thanks.
In fact it worked that way, an all-uppercade handle.
Best regards.
Mario Guerra - NIC-CR
________________________________
De: Jiří Morariu <jiri.morariu(a)nic.cz>
Enviado: martes, 16 de julio de 2024 05:39
Para: fred-users(a)lists.nic.cz <fred-users(a)lists.nic.cz>
Asunto: RE: A curious behaviour for a FRED client
Hello Mario.
Thank you for letting us know about an issue related to lowercase chars
in registrar's HANDLE. We can reproduce it. The reason of this behavior
is the fact FRED uses UPPERCASE handles (except of the fqdn) including
registrar's one. Clients (fred-admin and FERDA) ensure the HANDLE is
stored to the fred DB in UPPERCASE.
We strongly suggest to use UPPERCASE registrar HANDLE. Here is a DB
constraint that should prevent non-standard input. We must warn you,
however, that you should definitely NOT run this constraint during
traffic. Ideally, we recommend scheduling a downtime and running this
during that downtime. We also recommend that you create a backup of the
database before running it.
Let us know how it went, and do not hesitate to contact us in case of
any problems.
Normalize data that does not fit the new constraint:
```
UPDATE registrar
SET handle = TRIM(UPPER(handle))
WHERE handle != TRIM(UPPER(handle));
```
After data normalization it is possible to create new constraint:
```
ALTER TABLE registrar
DROP CONSTRAINT registrar_handle_check,
ADD CONSTRAINT registrar_handle_check CHECK(TRIM(UPPER(handle))
= handle AND handle <> '');
```
Best regards
--
Jiří Morariu
System administrator
---------------------------------
CZ.NIC, z.s.p.o.
Milešovská 5
130 00 Praha 3
e-mail: jiri.morariu(a)nic.cz
web: https://www.nic.cz/
---------------------------------
_______________________________________________
fred-users mailing list -- fred-users(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
53
days inactive
65
days old
5 comments
3 participants
participants (3)
-
Jiří Morariu -
Mario Guerra -
Piotr Przybyl