NCALayer is Not Working: Causes, Solutions, and E-Signature Automation

Almost every business in Kazakhstan has lost an hour of work time at least once due to one line: "Error connecting to NCALayer. Make sure the program is running." At this moment, everything stops immediately — logging into egov.kz, submitting an application for government procurement, issuing an electronic invoice, sending a report to the taxpayer's cabinet. The reason is almost always the same, and it is technical: NCALayer is a small local server that lives on your computer and listens to port 13579 at address 127.0.0.1. When you click "Sign" in the browser, the page knocks not on the government server, but right here, on your own machine. If this bridge falls, no e-signature goes through, even though the key and password are in perfect order. Therefore, when NCALayer is not working, the issue is rarely with the signature itself.

Over the past year, the context around electronic digital signatures has changed significantly. Since August 2025, obtaining an e-signature has been completely moved online — a visit to the Public Service Center is only needed if biometric verification fails after five attempts; the signature itself is still free for individuals. An alternative to the desktop has also appeared — signing via QR code through eGov Mobile. At West Star Ltd, we encounter e-signatures from both sides every day: we help client employees overcome NCALayer's quirks at workplaces and simultaneously integrate signing into business processes where a person does not approach the browser at all. This article is about both sides: why the layer breaks, what to fix first, and when it's time to move away from manual NCALayer altogether.

Why NCALayer is Not Working and How the Layer is Structured

To fix it, you need to understand what exactly broke. NCALayer from the National Certification Authority of Kazakhstan is not a "signing program" in the usual sense, but a mediator between the browser and your key. It establishes a secure WebSocket connection (wss://127.0.0.1:13579) on the computer and waits for the web page to request data signing. The standard port is 13579, but in case of conflict, the application can occupy any from the range 13579–13679, a total of a hundred ports. You can check if the bridge is alive in ten seconds: open the address 127.0.0.1:13579 in the browser — if a blank page appears without a certificate error, then the program is running and listening to the port.

Then begins the list of reasons why the connection to NCALayer is interrupted or not established at all. In our practice, problems almost always boil down to several scenarios:

• The program is simply not running or minimized in the tray after a reboot — the most common and most annoying case.
• Port 13579 is occupied by another process. This especially affects those who work in 1C via RDP sessions: several users on one server fight for one port.
• Antivirus or its secure connection verification module replaces the SSL certificate and breaks the handshake. It is treated with the option "do not check secure connections" for the local address.
• The root certificates of the National Certification Authority of Kazakhstan are not installed, or the browser and operating system do not trust them.
• The firewall or corporate network blocks the local connection.
• An outdated version of NCALayer itself or a conflict with a fresh browser version.

What to check when NCALayer is not working, in order: make sure the program is actually running (icon in the system tray); restart it — this removes a good half of the freezes; open the address 127.0.0.1:13579 and look at the response; temporarily disable HTTPS verification in the antivirus; reinstall the fresh version from the official site pki.gov.kz and reinstall the root certificates. If you work in RDP — configure NCALayer to run on a separate port for each session, otherwise users will knock each other out. In the overwhelming majority of inquiries we analyze, one of these steps helps, and it doesn't even reach the dramatic "the e-signature broke" — the problem is in the environment, not in the key.

A separate headache is updates. The National Certification Authority of Kazakhstan periodically changes requirements and releases new versions of NCALayer, and the combination of "old layer plus fresh Chrome" breaks for no apparent reason: a signature that worked yesterday gives an error today. Therefore, in case of failure, it is worth checking not the key, but the version of NCALayer and the browser and keeping both up to date. In a corporate environment, it is more convenient to solve this centrally, rolling out the update to all machines at once, rather than chasing each user individually.

Server Signing: How Business Moves Away from Manual NCALayer

Here it is important to see the bigger picture. NCALayer is designed for one scenario — a live person sits at their computer, opens the browser, and clicks "Sign." For one accountant, this is normal. But as soon as the documents become tens and hundreds a day, the desktop layer turns into a bottleneck: each invoice, bill, or act must be signed by someone manually, and any NCALayer failure stops the entire conveyor and rests on one person with one computer.

For people, there is already a way out — signing via QR through eGov Mobile: the site shows a code, you scan it with your phone and confirm with a fingerprint or Face ID, without any layer on the PC. This is convenient for one-time operations and gradually removes some of the load from NCALayer. But for the flow of documents, a different approach is needed — signing in which a person does not participate at all.

This is exactly what server signing is for. The open solution NCANode is a cross-platform server (Windows, macOS, Linux) that can do the same as NCALayer, but via API: sign and verify documents, read PKCS12 key data and X509 certificates, build a trust chain to the root certification authority. It supports CAdES, XAdES, and PAdES signature formats at levels from B to LTA, works over HTTP and through the RabbitMQ queue, communicates in JSON format, and is deployed as a ready-made Docker image. Essentially, instead of an employee clicking in the browser, your accounting system itself sends the document for signing and receives the signed file back in fractions of a second. In Kazakhstan, both small startups and large insurance companies already work this way.

How it looks in practice. 1C generates an invoice, sends it to the signing server by event, the server signs the document with the organization's key and returns the signed file, which immediately goes to the state system or the counterparty. Not a single click, not a single open browser, not a single "NCALayer is not working" in the middle of the workday. On a flow of hundreds of documents, such a conveyor works around the clock and does not depend on whether the accountant's computer is on and whether the layer is running. When we set up such signing and document flow automation, the e-signature ceases to be a separate action and becomes part of the process. We link this with 1C and external systems integration so that signed documents immediately go where they need to — to the electronic invoice, CRM, or the counterparty's personal account. We collect related cases on system docking in a separate section of integration materials.

Limitations and Risks of Server Signing

Server signing is not a silver bullet, and honestly naming its weak points is more important than beautifully selling the idea itself. What you should remember in advance:

• Key storage. To sign without a person, the private key of the e-signature must constantly lie on the server. This is convenient and simultaneously dangerous: a compromised server means a compromised company signature. Isolation, storage encryption, and strict access control are needed.
• Legal responsibility. Automatic signing is legally significant just like manual. If the system signed the wrong document due to a logic error, the company will be responsible, not the "program."
• Not everything can be automated. Some government portals still require exactly interactive signing through NCALayer or eGov Mobile and do not accept server calls — bypassing here is impossible and unnecessary.
• Support and updates. Formats, root certificates, and requirements of the National Certification Authority of Kazakhstan change; the open NCANode has to be updated and tested, otherwise one day the signature will stop passing verification.
• Entry threshold. Deploying a server, closing its perimeter, and linking it with 1C — this is an engineer's job, not "installed and forgotten." For five documents a month, such a project simply will not pay off.
• Single point of failure. A centralized signing service is convenient to monitor, but if it goes down, the entire flow stops immediately — backup and notifications are needed.

These limitations do not negate the benefits of automation — they outline where it is appropriate. A small business with a dozen documents a week is enough to put the desktop NCALayer in order once. A company that signs hundreds of documents, the server solution saves man-hours and removes a whole class of errors, but requires a mature approach to key storage security.

What to do next depends on the role. A specialist who encounters "NCALayer is not working" every day should go through the checklist above once and fix the working configuration — this will remove most incidents. A department head should calculate how many man-hours per month go to manual signing and compare with the document flow: beyond a certain threshold, manual labor costs more than automation. For the owner, the strategic fork is more important — to stay on desktop signing while volumes are small, and to switch to server signing with integration into accounting systems when document flow becomes part of the production process, not a one-time formality. Electronic signature in Kazakhstan has long ceased to be just a "file with a key"; the question is only whether it works for you or you for it.

Frequently Asked Questions

Why is NCALayer not working, even though the key and password are correct?

Because the problem is almost always not in the key, but in the local bridge. NCALayer establishes a connection on port 13579 of your computer, and if the program is not running, the port is occupied, the antivirus breaks the secure connection, or the root certificates are not installed — the signature will not go through even with an absolutely correct key. Start by restarting the program and checking the address 127.0.0.1:13579.

How to check if NCALayer is running?

Open the address 127.0.0.1:13579 in the browser. If a blank page loads without a certificate warning — the layer is working and listening to the port. If the browser gives a connection error, then NCALayer is not running or the port is blocked, and it needs to be restarted or reinstalled from the official site pki.gov.kz.

Can documents be signed without NCALayer?

Yes. For one-time operations, signing via QR code through the eGov Mobile app is suitable — the layer on the PC is not needed in this case. For the flow of documents, server signing via API (for example, through NCANode) is used, when the accounting system signs files itself, without human participation and without desktop NCALayer.

Does the business need a server NCANode or is a regular NCALayer enough?

It all depends on the volume. If the company signs several documents a week, a properly configured desktop NCALayer is enough. If it is about hundreds of invoices and acts, server signing with integration into 1C pays off due to saved hours and fewer errors — but requires attention to key storage security.