Customers who're using interfaces like CM2000, E-Invoices, Supplier Return, and others, along with Mosaic Finance, and even CP-IS files to the NHS Spine, all rely on systems that transfer files back and forth. This ensures they're keeping their information up to date and communicating with each other. As a result, Mosaic can correctly invoice, and bill based on the actual care provided. Similarly, the NHS can maintain current information on children at risk.
This system of file transfers between Mosaic and one of the described interfaces above is done by scheduled jobs where the job is programmed to know:
what host SFTP server it is to connect to.
what are the credentials for that server.
where it picks files up and drop files off on that server.
and crucially in this case whether the server can be trusted to become a known host.
The system transfers files between Mosaic and one of the described interfaces above, its done by scheduled jobs where the job is programmed to know:
What host SFTP server they're connecting to.
What the server's credentials are.
Where to pick up and drop off files on that server.
And crucially, whether the server can be trusted to become a known host.
The last point is done by storing a unique 'fingerprint' signature of the SFTP server to a configuration file on the Mosaic end, which assists the jobs in authenticating the SFTP server as being trusted that they are automated to dial on to.
Trouble can arise with the running of these jobs when the other parties SFTP server (it could be the CM2000 call confirm servers, or a customer's own SFTP server that they use as a landing post to collect AP, AR, or CP-IS files) has some changes or work done to the server which then changes the SFTPs own fingerprint that it broadcasts to incoming connections who're trying to connect to it such as our Mosaic jobs.
This can happen:
When certificates are updated on that server, or
A new fingerprint is explicitly generated, or
Other infrastructure work on that SFTP Server, or
A SFTP server is replaced.
Before connecting to an SFTP server, our Mosaic jobs will check if the fingerprint that the SFTP server is broadcasting back to us and cross reference it against the trusted fingerprint we have for that server within our trusted hosts configuration file.
If the Mosaic job detects a mismatch, it immediately halts, fearing it's a malicious server it can't trust. This is in the interests of the customer that the jobs quits there and asks for reassurance for if a malicious actor slotted their server in between the process (man-in-the-middle attack), then that would see us sending files to a side with bad intent, or receiving files from that bad actor that go into Mosaic with incorrect information to potentially corrupt case work. This is a necessary failsafe to have.
In practical terms, if this isn't resolved, every time the job runs it won't work. This will lead to a backlog of files starting to pile up on both servers, which will be unplugged once the fingerprint issue is resolved.
The solution is to replace the old fingerprint with the new one, which will let the jobs get back on track with their schedule.
For hosted customers please raise a new case online and reference the title of this article.
Please specify which interface is being affected (i.e. CM2000 invoice imports not being received) or not receiving up to date information, and if the SFTP server in question is the customers own SFTP server then could you inform us:
What work was carried out if known?
What is the RSA fingerprint that our jobs are expected to trust and agree with?
We will then be able to make the changes you need.