I have done this, according to http://www.tc.umn.edu/~brams006/selfsign.html, part 1B (generating your own CA):
a) create a CA authority (ca.key and ca.crt)
b) make a certificate request (server.csr)
c) sign the certificate request (server.crt and server.key) with the new CA authority
d) change the server key so it does not ask for a passphrase.
Afterwards, the server.crt and server.key files are included in /usr/share/fred-client/ssl directory, and the fred-client configuration file is modified like this:
ssl_cert = %(dir)s/server.crt
ssl_key = %(dir)s/server.key
Now, if I try to run fred-client this is the result:
ERROR: socket.sslerror: [Errno 1] _ssl.c:480: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca (200.107.82.18:700)
Certificate not signed by verified certificate authority
What should I do for fred-client to identify these certificates as valid?.
Thanks in advance.
Note: the new fred-client is perfectly compatible with FRED 2.2.
--
Mario Guerra <mguerra(a)nic.cr>
Hi,
I've came accross a case where calling EPP contact:update command with disclosure settings {"flag": "n", "data": ["addr"]} returns "Operation not permitted" for contact with "identifiedContact" flag.
According to rules for hiding contact address in .CZ (https://háčkyčárky.cz/files/nic/doc/Pravidla_Technicke_Komunikace_20191115.…) this should be allowed.
Can you please confirm the rules are still valid?
Thank you.
FRED bad exDate result in poll
==========================
We are seeing a different (bad) result of exDate in poll messages compared to that in the
WHOIS or in the info_domain EPP command result for some domains follwoing a database
change, please allow me to explain.
At least one registrar in the past year has requested a roll back of the expiry date of a .mw
domain following a mistake by staff of the registrar who put more years on the domain renew
than what was paid for. We normally resist rolling back the expiry date but in these cases we
had no choice.
What was done was to run an SQL command on postgres to change the expiry dates say
from 2023 to 2022.
What we have noted is that when this is done the WHOIS will report the correct 2022 expiry
date, the info_domain EPP command reports the same 2022 expiration date but when the
"fred-admin --object_regular_procedure" is excuted and then we run the "poll req" EPP
command, it still gives the 2023 exDate
Would be interesting to find out why this is the case.
This is confusing the registrar managing such a domain and we would like to ask that these
dates should be the same in any future FRED uogarde.
Or is there a better way of rolling back the expiry date for a domain that has mistakenly been
given more life years than wanted ?
Regards,
Paulos
=============================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD
http://www.nic.mw
SDNP: http://www.sdnp.org.mw
Tel: +265-(0)-882 089 166
Cell: +265-(0)-888-824787
WhatsApp: +265-(0)-887386433
--
This email has been checked for viruses by AVG.
https://www.avg.com
