How to generate a KSeF certificate

As of June 6, 2026, you can generate a KSeF certificate in the KSeF 2.0 Taxpayer Application. After signing in, check the identifier used for authentication, open the Certificates tab, select Apply for a certificate, enter a name, set a password, and generate a local private key as a .key file.

Next, select one certificate purpose and a validity start date, then submit the application. When the process is complete, download the public certificate as a .crt file. The .key and .crt files serve different purposes, and you need the correct matching pair to use the certificate.

KSeF does not store the private .key file and cannot recover it. Before closing the form, confirm that the file has been downloaded, store the password securely, and create a controlled backup.

A taxpayer or an authorized person may apply for a certificate. In the KSeF 2.0 Taxpayer Application, the user authenticates with an available sign-in method, such as a Trusted Profile signature, a qualified electronic signature, or a qualified electronic seal. A KSeF certificate is not used to sign in to the Taxpayer Application interface, but it can be used for authentication in properly integrated software that communicates with the API.

Before you begin, check both the context selected in the Taxpayer Application and the identifier contained in the authentication method you are using. The application data is obtained during sign-in, and the certificate will be issued for the owner's identifier. However, the company context and the scope of operations are not permanently stored in the certificate. When the certificate is later used, KSeF checks its owner's current permissions.

You should also prepare a secure location for the .key file and decide how the password will be stored. Do not leave this decision until the end of the process. The private key is created locally, and losing it means that you must obtain a new certificate.

A KSeF certificate is issued for the identifier obtained from the authentication method. This may be a NIP, PESEL, or the fingerprint of a qualified certificate if the signature or seal does not contain a tax identifier. The certificate does not grant permissions by itself and is not permanently assigned to one company context.

Type 1 and type 2 certificates have different uses and require separate applications. Type 1 is used for authentication, while type 2 is used to sign the issuer verification link in offline modes.

Saving the .key file is the most important moment in the process. You can download the public .crt certificate again, but neither the private key nor its password can be recovered from KSeF.

The application offers two certificate purposes. The first is Authentication in the KSeF system, which corresponds to a type 1 certificate. The second is Signing the issuer verification link, which corresponds to a type 2 certificate.

A single certificate cannot combine both purposes. This does not mean that every company needs two certificates. The choice depends on how the integration will authenticate and whether the company issues invoices in offline24 mode, during system unavailability, or during an outage.

Before submitting the application, check the documentation of the software that will use the certificate. The provider should clearly identify the required purpose. The terms type 1 and type 2 are useful in technical discussions, but in the form you should follow the full certificate purpose name.

1. Open the official KSeF 2.0 Taxpayer Application and start the sign-in process. Do not follow outdated instructions that direct you to the former Certificate and Permissions Module. January 25, 2026 was the last day applications could be submitted there, and a technical break took place from January 26 through January 31 before KSeF 2.0 was launched.

2. Authenticate with a supported sign-in method, such as a Trusted Profile signature, a qualified electronic signature, or a qualified electronic seal. You cannot use a KSeF certificate to sign in to the Taxpayer Application interface. Applying after certificate-based authentication is possible through the API in properly integrated software, but authentication with a KSeF token does not allow you to submit a certificate application.

3. Check the context and the owner's identifier. A method containing a PESEL results in a certificate issued for that identifier, while a method containing an entity's NIP results in a certificate containing that NIP. If a qualified signature or seal contains neither a NIP nor PESEL, the identifier may be the fingerprint of the qualified certificate. Subsequent access and the scope of operations depend on the certificate owner's current permissions.

4. Open the Certificates tab and select Apply for a certificate.

5. Enter a certificate name. It should contain between 5 and 100 characters and may include Polish letters, digits, spaces, a hyphen, and an underscore. KSeF_CompanyX_authentication_2026 is an example that can help organize your records, not a Ministry of Finance requirement.

6. Set and repeat the private key password. The password must contain between 15 and 32 characters, including a lowercase and uppercase letter without Polish diacritics, a digit, and at least one character from this set: !@#$%^&*()-_=+. The password cannot be reset later.

7. Select Generate. The browser will save the private key on your device as a .key file. Check the downloads folder immediately and make sure the file exists. Do not continue until you have confirmed it.

8. Select one certificate purpose: Authentication in the KSeF system or Signing the issuer verification link. If you need both functions, complete a separate process for each certificate.

9. Select the validity start date. A certificate may be valid for no more than 2 years, and its validity may begin in the future. When replacing a certificate, allow enough time to activate and test the new one before withdrawing the previous certificate.

10. Select Submit certificate application. Refresh the screen until processing is complete, then use the Download certificate option.

11. Check the complete set. It should include the local private .key file, the public PEM certificate with the .crt extension, and the saved password. The .crt file alone is not enough to use the certificate without the corresponding private key.

The .key file is not a certificate. It contains the private key generated locally in the browser and protected with the password you selected. Do not send it by email, place it in a shared directory without access controls, or provide it to anyone who is not responsible for the integration.

The .crt file is the public certificate in PEM format. You can download it again from the list of active certificates, but it cannot replace a lost .key file. The pair must come from the same generation process.

The safest approach is to keep the key in an encrypted store with restricted access, create a controlled backup, and store the password separately. Your internal procedure should identify the certificate owner, the system using the key, and the person responsible for replacing it before expiry.

The Certificates tab contains the list of issued certificates. The application distinguishes between active, blocked, revoked, and expired statuses. Simply possessing the .crt file does not confirm that the certificate can still be used.

On the list, check the purpose, owner identifier, valid from date, valid until date, and last used date. These fields help identify a certificate issued for the wrong identifier, an approaching expiry date, or a key that is no longer used.

You can download an active .crt file again. However, the list cannot restore the private .key file. If you no longer have it, downloading the public certificate will not restore your ability to authenticate or sign.

The most serious mistakes occur before you select Submit application. An incorrectly identified owner or the wrong purpose may result in a certificate that does not match its intended use. The context should be checked as part of your internal process before starting the application, but it is not permanently recorded as the certificate's operating scope.

The second group of mistakes concerns the files. A user downloads the .crt file but does not notice that the browser failed to save the .key file earlier. Downloading the public certificate again cannot fix this problem.

KSeF limits the number of certificates that may be issued, but you should not assume the current value based on old instructions or vendor materials. If the application reports that the limit has been reached, check the current limit and review unused certificates without guessing the number.

Revoke the certificate immediately if you suspect that the private key has been exposed, copied by an unauthorized person, or stored on a device or in a repository that is no longer under your control. Deleting the local file does not change the certificate's status in KSeF.

The application provides three revocation reasons: replacement with a new certificate, private key security compromise, and unspecified reason. Select the reason that reflects the actual situation and record the decision in your company's access register.

Certificates are revoked individually and only within the scope of your own certificates. After revocation, identify every system that used the old key and arrange a controlled replacement with a new set.

Complete every item before giving the files to an administrator or software provider. This review helps you identify an error while you still remember the application context and where the key was saved.

1. The certificate was issued for the correct owner identifier.

2. The correct purpose was selected: authentication or signing the issuer verification link.

3. The validity start and end dates match the deployment plan.

4. The .key file is stored in a secure repository.

5. The .crt file has been downloaded and assigned to the same set.

6. The password has been tested and stored separately.

7. A controlled backup of the key has been created.

8. Access is limited to designated people or systems.

9. The expiry date has been added to a calendar or register.

10. Certificate replacement has been planned before the validity period ends.

Do not wait until the final day of validity. Record the owner, purpose, system using the key, expiry date, and person responsible for deploying its replacement in your certificate register.

Start early, generate a new set, and test it during a controlled maintenance window. The new and old certificates can operate in parallel for a planned period, allowing you to verify the configuration before withdrawing the previous key.

After switching, test authentication or verification link signing, monitor the first operations, and only then remove the old key from your systems. If the old key has been exposed, do not wait for the planned rotation. Revoke the certificate immediately.

After creating a KSeFGPT account, you will see an onboarding flow for the initial setup. Add a company, then choose to connect it to KSeF. The system will redirect you to Settings, the KSeF Connection tab, and the KSeF Credentials section.

1. In Settings, open the KSeF Connection tab and find the KSeF Credentials section for the correct company.

2. To connect the company with a certificate, select the private key in .key or .pem format and its matching certificate in .crt, .cer, or .pem format. Both files must come from the same certificate generation process. If the key is encrypted, enter the password set when it was generated.

3. To use a token, select Token and enter a token generated in the correct company context with the permissions required for the planned operations.

4. Check the selected company and authentication method, then save the credential.

5. After the connection has been saved successfully, open the Invoices module. With certificate authentication, KSeF checks the certificate owner's current permissions. With a token, access depends on the context and permissions stored in the active token. If these requirements are met, you can retrieve and view the available invoices.

Do not send the certificate, private key, or token by email or instant messenger. Add them directly through the KSeF Credentials form in your account.

If you are choosing an authentication method, read KSeF token or certificate? A practical authorization guide. Use it to compare the methods, then follow the current certificate procedure described in this article.

The next stages are covered in Sending invoices to KSeF: complete 2026 guide and UPO in KSeF: what is the Official Confirmation of Receipt?.

Before a wider rollout, you should also read The most common KSeF implementation challenges and how to overcome them.