Need help in member registration of SS to CS
KaHustOwOd opened this issue · 21 comments
Hi everyone. It's me again. I'm having a problem with the work of member registration process which a SS get along to a CS. I'm at the step of importing signed auth/sign certificates to SS.
Here comes my error: Whenever I import the signed sign certificate to the SS, I move my GUI to the pane of diagnostics, waiting for the good sign of OCSP responders but it always didn't happen. The status switches from the yellow to red and the message of each update/restart is "unable to connect to the OCSP responders". The reason why I know this is my "itch" is that whenever if I delete the sign certificate that I have just imported, the status of the OCSP responders will turn back to the yellow waiting status again.
Anyone met this problem? Can you help me please?
Hello,
Have you verified that the service is running and is accessible for the security server host on that URL (http://10.0.2.4:8888)?
Yeah, sir, thank you for replying my issue again.
I have checked by the command "systemctl" of all the services that CS needs: ocsp, nginx, tsa, ca and it's still running (enabled)
I have conducted the command "telnet" the CS-ip (10.0.2.4) at 2 ports: 8888 and 8899 from the SS hostmachine and the work is still OK.
I'm wondering whether the metadata of certs (including ocsp, tsa, ca), which is organization (O), country (C), common name (CN) of subject and issuer, needs to be the same with the metadata of newcerts (including signed sign and auth certificates) or not? In the configuration process, I did it ordinally, whereby I supposed that those bunches of info belong to 2 different system (and don't need to fit each other). I have tried to fix this issue for a week yet.
What certificate profile are you using for the CA service?
Could you also please share the proxy and signer module log files?
sorry sir, I don't get the meaning of certificate profile. Do I need to provide all the details of CA service's certs including: key infos, extension, signature, etc?
I also don't find out the file proxy.log, where is it usually locate, sir ?
And here is my signer.log for today (August 10th) (the previous had been auto-zipped and I can't extract it)
In the previous days, I got some kind of error shown in the signer.log called "SSL message"
(p/s: Sorry for the resolution of images if it's hard to see, my ethernet driver on my PC somehow had been crashed, I have to take the picture and upload it by my phone. I will fix the ethernet issue in the following days.)
No, I mean the certificate profile you set up in the Central Server when configuring the Certificate Authority (CA) service. You should also be able to view it now if you go to the Central Server web UI and open the services details page.
Unfortunately, the picture logs don't give us enough information. It does claim that the softToken is not active. Have you logged into it?
Could you please share the proxy and signer log files from /var/log/xroad? The log files should be from when you encountered the error so we can investigate further.
Sorry but I really don't see the proxy.log in the path /var/log/xroad, I can only see the jetty.log, audit.log, configuration_client.log and signer.log here.
Here is my certificate profile:
I surely logged into softtoken whenever I reopen the SS, the reason why it's happening again and again probably because I have restarted the services of machine too much or "out of login session".
I will upload the rest of the signer.log in the previous days later when the ethernet issue is done. Please keep my problem in your charge... If the description isn't enough, I will upload the rest nearby next Monday or Tuesday.
I have check the path again and I found out the proxy.log. I will upload it later for you, please keep in charge with me.
Hi @raits, it's me again. I can't fix my Ethernet card. Somehow it has fallen into "deep sleep mode". I conduct some tools to get what I needed out by USB
But here's my proxy.log and signer.log of my SS.
(proxy10/8/2023)
proxy.2023-08-10.0.log
(signer10/8/2023)
signer.2023-08-10.0.log
(proxy16/8/2023)
proxy.2023-08-16.log
(signer`16/8/2023)
signer.2023-08-16.log
Hi, please reply me. I'm desperate and I suppose to reboot the Windows to do everything from scratch, also restart my untreatable Ethernet. I don't wanna make any downfall without intention :(
Hey, looking at the signer logs there seems to be an error connecting to the OCSP server:
e.r.x.s.certmanager.OcspClientWorker - Unable to connect to responder at http://10.0.2.4:8888/ java.io.IOException: Invalid http response code from responder: 502
The error code suggests that the OCSP service is not running correctly. I would suggest that you look at the logs on your OCSP service and verify it is configured correctly.
Thanks for the urgent help, i figure out this already but I don't know how to solve it at all. My ocsp.log is empty. I did consecutively all the instructions while installing the TestCA.
How about the nginx logs that host the test CA? Do they contain some helpful information?
I dont figure out the nginx.log files in my testCA folders. I only see the code called ca.nginx and tsa.nginx to pass the proxy through the default ports.
Oh i see the log of nginx now, there are access.log, error.log, error_ocsp.log, localhostaccess.log, which one do you want me to extract out for uploading?
It would be good for you to have a look at them and see if there is useful information inside, most likely it will be in the error.log and error_ocsp.log files though.
Hi, here is my error.log and error_ocsp.log for today
error:log
error.log
error_ocsp.log
error_ocsp.log
I guest it is not useful enough to fix :(
Are you able to access the Test CA UI on port 8888: http://test-ca-host:8888/testca/
Could you also please give more information on how you set the Test CA up, did you use or Ansible scripts or did you attempt to do so manually?
I did it manually sir, what I did is follow the instructions of configure provided by nordic-institute.atlassian.net.
I guest I found out bug here. It may comes from 2 small itches:
- Once I do the command: "sudo rm .init" to re-configure my certs, the privileges of accessing the whole directory path "/home/ca/CA" had been changed. Then I have to keep my mind to set it again by: "sudo chmod -R 775 /home/ca/CA".
- In the "init.sh", the parameters shouldn't have the symbol of "-" or "_". I delete those symbols and add it again to test the cases and the results assert that. Idk if there was a syntax note at this stage.
+3) I provide the authority with the path "/var/log/ocsp.log" for (user ca) with the command: "chown ca:ca /var/log/ocsp.log" (but the ocsp.log is still empty)
Those are the procedures that I think contribute the most to make my OCSP responders changing its status from "unknown" to be "good".
.
.
.
.
.
.
.
.
.
.
(Oh, one think more I want to share, this is for anyone meets the errors after me: If you don't install nginx.service, you should change at the HTTPServer line of code: "localhost" -> "0.0.0.0" to make it run)
Thanks @raits for your devoted help. If there is any error, I would post another issue here again.
Glad to hear you were able to resolve it, and thank you for also writing about your solution for others who might come across this issue @KaHustOwOd.