Certificate Registry

[hainguyen291]

Hi @petkivim ,

I am going to send registry request from Security Server to Central Server as image below.

However, I got error Failed to register certificate: Member 'MEMBER:XROADVN/GOV/VPCP03' has no suitable certificates when tried to registry with public IP: 10.0.5.133, which is NAT via firewall to 10.9.32.86.

10.9.32.86 is my internal IP, meanwhile 10.0.5.133 is its public IP. I can access this computer via internal IP via VPN as you see on the image. I tried both internal IP and public IP to send registry request but all are failed. Please let me know what I should to do now?

Best regards, Hai

[hainguyen291]

TCP 80, 443 - Ports for outbound connections (from the security server to the external network) Most common OCSP and time-stamping services

Do I need to open firewall for ports 80 and 443?

[petkivim]

Hi @hainguyen291

It seems that the Security Server hosting the Management Services does not have a valid certificate yet. You're trying to register a certificate for a Security Server which server code is VPCPSS03 and the error message says that server VPCP03 has no suitable certificates. First you must complete the configuration of VPCP03 and only after that you can register more Security Servers. Please check that you have completed steps 1-12 in section 3.3:

https://github.com/nordic-institute/X-Road/blob/develop/doc/Manuals/ig-cs_x-road_6_central_server_installation_guide.md#33-configuring-the-central-server-and-the-management-services-security-server

All 10.* IP addresses are private so you cannot have public IPs in that IP range.

https://en.wikipedia.org/wiki/Private_network#Private_IPv4_addresses

Regards, Petteri

[petkivim]

Do I need to open firewall for ports 80 and 443?

If OCSP and TSA are running on those ports in an external network, then outgoing network connections must be allowed from Security Server.

[hainguyen291]

Hi @petkivim

I am using VPCPSS as security server hosting management services.

By doing like this, I have registered SS01 successfully

My OCSP and TSA are running on ports 8888 and 8899.

[petkivim]

Does VPCPSS03 have a sign certificate?

[petkivim]

My OCSP and TSA are running on ports 8888 and 8899.

You must allow outgoing traffic to ports 8888 and 8899.

[hainguyen291]

VPCPSS03 has sign certificate already

[hainguyen291]

Do you mean outgoing traffic of public IP 10.0.5.133 NAT via firewall to 10.9.32.86 or 10.9.32.86 itself? Although 10.9.32.86 is belonged to private network, but we still can use public IP (10.0.5.133) to NAT via firewall and router to .86 because our CS is also at the same network.

[hainguyen291]

123.31.27.101 is public IP, but internal IP of this one is 10.0.14.227. This is our CA server, where we deployed OCSP and TSA server too.

[petkivim]

OCSP status of the sign certificate is unknown - that's the reason why the request fails. You should wait that the status is good.

[hainguyen291]

Here is .86's diagnostic

And it seems that my OCSP http://10.0.14.227:8888 is in good state, doesn't it?

[hainguyen291]

You should wait that the status is good.

Do I need to do something with OCSP or just wait until status is good?

[hainguyen291]

Should I remove SS on .86 and reinstall it again?

[petkivim]

You have two OCSP responders there and the status of the first one is red. The first one uses the public IP and the second one the private IP. The Security Server is probably trying to connect the first one which is not accessible at the moment. You could try to remove the first one from configuration as the second one is working. That should solve the problem.

[hainguyen291]

I did remove the first one and keep the working one.

However, my sign certificate status still be unknown

The .86 is behind a firewall, that's why we need to connect via 10.0.5.133 as public IP in this private network. My CS can ping and telnet to 10.0.5.133

And my .86 can ping and telnet to my CS server, whose private IP is 10.0.14.227

[hainguyen291]

I think that, the ocsp response status is unknown because of .86 cannot get response from .227 (OCSP servers). As we know that, .86 is behind a firewall, which we can only access inbound via .133. Once OCSP server gets a request from .86 (outbound), so It should give a response back to .86 instead of .133 ( it even doesn't know exist of .133). However, we cannot access inbound directly to .86 without going through .133, that is why .86 don't get any response from OCSP.

Unknown (validity information missing) – the certificate does not have a valid OCSP response (the OCSP response validity period is set by the X-Road governing authority) or the last OCSP response was either “unknown” (the responder doesn't know about the certificate being requested) or an error.

So, I think we should customize OCSP server, don't we? Do you have any resolution for this problem?

Best, Hai

[petkivim]

I think that there's no need to customize the OCSP service. The problem should be solved updating the network and/or firewall configuration.

And my .86 can ping and telnet to my CS server, whose private IP is 10.0.14.227

Are you able to ping from .86 to .227 ports 8888 and 8899?

Is your firewall stateful or stateless? In case it's stateful, it's enough to allow outbound connections from .86 to .227:8888 and .227:8899. In case it's stateless, in addition to outbound connections, on .86 you must also allow inbound connections to ephemeral ports (1024-65535) from .227.

[hainguyen291]

I can telnet from .86 to .227 via ports 8888 and 8899

However, I cannot ping from .227 to .86 directly. I need pass by .133, which is NAT via firewall to .86. Is this the reason why OCSP server response, which serve for .86 request, cannot reach .86?

[petkivim]

I can telnet from .86 to .227 via ports 8888 and 8899 However, I cannot ping from .227 to .86 directly.

Requests are always initiated by .86 (.86 => .227) so direct access from .227 to .86 should not be required.

Is the OCSP service working properly on your other Security Servers at the moment? The only one that has problems is .86? Just to be sure, because based on your tests using telnet the connections should work.

[hainguyen291]

Yes, it works with SS .104. And I used .104 as SS host management services

On Sat, Sep 8, 2018 at 4:29 PM Petteri Kivimäki notifications@github.com wrote:

I can telnet from .86 to .227 via ports 8888 and 8899 However, I cannot ping from .227 to .86 directly.

Requests are always initiated by .86 (.86 => .227) so direct access from .227 to .86 should not be required.

Is the OCSP service working properly on your other Security Servers at the moment? The only one that has problems is .86? Just to be sure, because based on your tests using telnet the connections should work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vrk-kpa/xroad-joint-development/issues/235#issuecomment-419626802, or mute the thread https://github.com/notifications/unsubscribe-auth/AMDkv1rxzvRzW0bRDqv5qugl-P31xopeks5uY435gaJpZM4WeiWY .

[hainguyen291]

@petkivim

I disable firewall on .227 and it suddenly works like magic???

I haven't had exactly answer, however the most important thing is it is working now. Thanks for your support, my friend.

Hai

[petkivim]

Great, that you got it working! :) The firewall might have blocked the response messages for some reason. It might be worth checking is the firewall stateful or stateless, and check the access rules after that.

Is your firewall stateful or stateless? In case it's stateful, it's enough to allow outbound connections from .86 to .227:8888 and .227:8899. In case it's stateless, in addition to outbound connections, on .86 you must also allow inbound connections to ephemeral ports (1024-65535) from .227.

[petkivim]

By the way, please submit your support requests to our current repository from now on:

https://github.com/nordic-institute/X-Road-development/

This repository is not used anymore.

[hainguyen291]

I got it @petkivim . Thank you.