Keep getting "but no presentation is available. Ignoring." and no connection.

[polemion]

2022-10-09T04:02:22.597981 [DEBUG] Resolving XX.XX.XX.XX:53765 for potential contact...
2022-10-09T04:02:22.598454 [DEBUG] No session exists with XX.XX.XX.XX:53765 (at XX.XX.XX.XX:53765). Contacting...
2022-10-09T04:02:22.598519 [DEBUG] Sending HELLO to XX.XX.XX.XX:53765
2022-10-09T04:02:22.630488 [DEBUG] Received HELLO_RESPONSE from XX.XX.XX.XX:53765 at XX.XX.XX.XX:53765. Latency: 00:00:00.031637
2022-10-09T04:02:22.740488 [TRACE] Received a SESSION_REQUEST from XX.XX.XX.XX:53765 but no presentation is available. Ignoring.
2022-10-09T04:02:30.808829 [DEBUG] Received HELLO_REQUEST from XX.XX.XX.XX:1024.
2022-10-09T04:02:30.948820 [TRACE] Received a SESSION_REQUEST from XX.XX.XX.XX:1024 but no presentation is available. Ignoring.

Hi,

I keep getting a "but no presentation is available. Ignoring." message when establishing a connection which keeps repeating as shown above and no connectivity is established in between the nodes.

I have no other errors on the debug output. No server, just peers, certificates are correct.

Any ideas?

[polemion]

OK, stupid me I guess.

The certs were correct, but I have used the ca.crt for the one node which didn't have the updated creds of the other node's certificate.

For anyone having the same issue on the future, first sign all of the certificates to the authority and then copy the ca.crt at the end :)

[polemion]

Scratch that, it worked once and then started having the same issue again.

Two machines, one Linux the other Windows.

The Linux machine is throwing the aforementioned error, the Windows machine does not.

It doesn't make any sense at this point.

[TJ-59]

I don't think the ca.crt is changed by signing new certs. The ca's private key is used to sign other certs, which means the resulting user cert is "only readable" through the ca's public key (aka the ca cert, aka everybody) which is okay since ONLY the CA could encrypt it with the private key, and its role is to tell everybody "I, the CA, signed his certificate, if you trust me, then trust him" ;
the user cert and private key work the opposite way, anyone can encrypt something for you, using your cert, but only YOU can decrypt it with your private key. If you want a user cert to be cancelled, you have to revoke it (done at CA's database level) and publish a Certificate Revocation List (CRL) which can be used by third parties to know WHO isn't trusted anymore by the CA.

concerning "but no presentation is available" it is located in /libs/fscp/src/server.cpp :

void server::do_handle_session_request(SharedBuffer data, const identity_store& identity, const ep_type& sender, const session_request_message& _session_request_message)
	{
		// All do_handle_session_request() calls are done in the presentation strand so the following is thread-safe.
		if (!has_presentation_store_for(sender))
		{
			// No presentation_store for the given host.
			// We do nothing.
			m_logger(log_level::trace) << "Received a SESSION_REQUEST from " << sender << " but no presentation is available. Ignoring.";

			return;
		}

(and more possible errors behind that), which seems to come from :

void server::do_set_hello_message_received_callback(hello_message_received_handler_type callback, void_handler_type handler)
	{
		// All do_set_hello_message_received_callback() calls are done in the same strand so the following is thread-safe.
		set_hello_message_received_callback(callback);

		if (handler)
		{
			handler();
		}
	}

	bool server::has_presentation_store_for(const ep_type& ep) const
	{
		// This method should only be called from within the presentation strand.
		presentation_store_map::const_iterator presentation_store = m_presentation_store_map.find(ep);

		if (presentation_store != m_presentation_store_map.end())
		{
			return !(presentation_store->second.empty());
		}

		return false;
	}

Not sure what it does exactly, as I'm only below basic (at best) at C++, but it seems to me that it checks (.find)for a presentation stored in the map (m_presentation_store_map), with the index being the sender's "ep", passed by reference (with &);
it puts what it can find in "presentation_store", then for whatever reason checks if what it just got is not the "after-last" element in "m_presentation_store_map" (which would mean it DID find something ?) and return the opposite of the check to see if it is empty (so, if it IS empty, empty() return True, and the real value returned is False; and in the other case, it's not empty (False) and returns True, and if all this fails, it returns False anyway.
(reminder, this is all to set the boolean "has_presentation_store_for" to True or False for the previous bit of code.)

You have to keep following that lead to see WHY you get no presentation. Is it something you did in the settings, or something about the way you made the certificates, only someone involved in C or one of the contributors could tell you.

[polemion]

I've found this part of the code-base too.
After spending more than 70 hours on this project, I didn't have time to explore it any further though.

Did follow the "official" guidelines on creating the CA certs as well as the configuration. I've even prepared a GUI tool for using Freelan (which I have now abandoned because of this), meaning I went to great lengths studying the configuration and whatnot, and tried numerous permutations to no avail.

The main-contributors seem to have lost interest on the project unfortunately (happens, I know by personal experience), so I don't expect anything on that front.

Anyway, thanks mate.

[TJ-59]

Could be that the certs are "ok" (from the creation POV) while not being "ok" after check (validity ?).
Just to be sure, could it be that you toyed long enough with those certificates/different machines that a MONTH went by ?
Default duration for certificate validity, including sometime the CA cert itself, is 30 days. Also, a user cert cannot be valid any longer than the CA cert it belongs to.
You'd need to edit the ca.cnf, and if it's already something like 10 years duration, be SURE to add the "-days 3650" option and argument when doing BOTH the CA cert+key generation, AND the user certs (csr signing). The ca.cnf -days option can be ignored by openssl depending on the version you use (OpenSSL 3 seems to ignore it), but the command line option and argument do work.

[polemion]

...that a MONTH went by ?

That is a very good point (and quite insightful) but I already had the same train of thought and did set them to 10 years as well as re-issued new certs on my tests.

I had set a ten year duration on the configuration file, plus the certificates were showing a 10 year expiration date afterwards,
but I haven't tried using the "-days 3650" option on creation. I will try it, thanks!