{"id":18985659,"url":"https://github.com/gematik/app-pkitestsuite","last_synced_at":"2025-08-10T12:11:39.803Z","repository":{"id":104011108,"uuid":"530955989","full_name":"gematik/app-PkiTestsuite","owner":"gematik","description":"PKI Testsuite to test products of the telematic infrastructure to fulfill the gemSpec_PKI specification. This test suite is used for approval tests of different products like VSDM Fachdienst, KIM Fachdienst, VPN Zugangsdienst, Intermediär, etc.","archived":false,"fork":false,"pushed_at":"2025-07-25T09:27:59.000Z","size":2113,"stargazers_count":11,"open_issues_count":0,"forks_count":5,"subscribers_count":9,"default_branch":"main","last_synced_at":"2025-07-25T15:35:52.993Z","etag":null,"topics":["cryptography","gematik","gemspec","idm","pki","pki-applications","testing-tools","testsuites"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/gematik.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":".github/CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":".github/CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":".github/SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2022-08-31T06:09:17.000Z","updated_at":"2025-07-25T09:21:54.000Z","dependencies_parsed_at":null,"dependency_job_id":"e4487fcc-76cd-4fa4-99e6-2ae04f6ec555","html_url":"https://github.com/gematik/app-PkiTestsuite","commit_stats":null,"previous_names":[],"tags_count":28,"template":false,"template_full_name":null,"purl":"pkg:github/gematik/app-PkiTestsuite","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Fapp-PkiTestsuite","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Fapp-PkiTestsuite/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Fapp-PkiTestsuite/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Fapp-PkiTestsuite/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/gematik","download_url":"https://codeload.github.com/gematik/app-PkiTestsuite/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Fapp-PkiTestsuite/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":269720530,"owners_count":24464310,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-08-10T02:00:08.965Z","response_time":71,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cryptography","gematik","gemspec","idm","pki","pki-applications","testing-tools","testsuites"],"created_at":"2024-11-08T16:27:35.547Z","updated_at":"2025-08-10T12:11:39.791Z","avatar_url":"https://github.com/gematik.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003cimg align=\"right\" width=\"200\" height=\"37\" src=\"docs/img/Gematik_Logo_Flag.png\"/\u003e \u003cbr /\u003e\n\n# PKI Test Suite\n\n---\n\u003cimg align=\"left\" height=\"150\" src=\"docs/img/PKI_Testsuite_Blau_gematik.svg\" /\u003e\n\nThis test suite is used to verify a telematic infrastructure (TI) product server of the German\nhealth care system against gematik gemSpec_PKI specifications available\nat [gematik Fachportal](https://fachportal.gematik.de/). Especially TUC_PKI_001 (TSL validation),\nTUC_PKI_018 (certificate validation) and TUC_PKI_006 (OCSP response validation). It is used for\napproval tests of every PKI related aspect. It is a re-development of our test suite from 2016.\n\nProducts tested by this test suite are: Intermediär, VSDM Fachdienst, VPN Zugangsdienst:\nRegistrierungsdienst and Konzentrator, IDP Fachdienst, IDP eGK Fachdienst, KIM Fachdienst. More are\ncoming.\n\n---\n\n## tl;dr\n\n#### setup with downloaded binaries\n\nDownload release zip file from https://github.com/gematik/app-PkiTestsuite/releases and extract it.\n\n``` bash \n# copy configuration file example and modify it (or use your own configuration)\ncp /docs/config/inttest/pikts.yml ./config/pkits.yml\n```\n\n#### setup from code\n\n``` bash \n# build the project\nmvn clean package\n# copy configuration file example and modify it (or use your own configuration)\ncp /docs/config/inttest/pikts.yml ./config/pkits.yml\n```\n\n#### Variant A: SUT is Your Test Object\n\n```bash \n./initialTslAndTa.sh # generates trust anchor and TSL in ./out for import in test object\n# The test object has to be started and accessible from now on.\n./checkInitialState.sh # acquires TSL sequence number from the test object by analysing a tsl download request and applying a use case\n./startApprovalTest.sh # chose tests that shall be executed from allTests.txt\n# Test artefacts (i.e. logs and report) can be found in ./out directory.\n```\n\n#### Variant B: SUT is the Simulator\n\nThe project contains a SUT Server Simulator. For a quick check if your generated binaries are\nworking, start this simulator instead of your test object and run the testsuite against it. This\nshould work ootb.\n\n``` bash \n# start SUT Server Simulator\njava -jar ./bin/pkits-sut-server-sim-exec.jar \u0026\n```\n\n```bash \n# run testsuite\n./startApprovalTest.sh\n```\n\n## Technical Functionality\n\nThe test suite consists of four parts necessary for validating a PKI test object. These are\nimplemented as maven modules and can be used independently or in conjunction with the test suite.\n\n### Requirements\n\nTo build and execute the test suite, you need Java 17 and Maven.\nThe test suite is developed and testet\nwith [Open JDK 17](https://openjdk.org/projects/jdk/)\n\n### 1. PKI Test Suite\n\nThis is the test suite itself. It is used to start all following modules, configure them and read\nthe results. It has\na [package](pkits-testsuite/src/main/java/de/gematik/pki/pkits/testsuite/approval/) with classes to\nall approval tests. The test suite calls a use case\n(see [Use Case Modules](./README.md#4-use-case-modules)) and expects it to either pass or fail,\ndepending on the test data used. If the expectation is met, the test case is passed.\n\nThe test suite has a couple of convenience options:\n\n```bash\njava -jar ./bin/pkits-testsuite-exec.jar --help\n```\n\n```text\nUsage: \u003cmain class\u003e [-h] [-np] [-faf=\u003cfailedTestCases\u003e] [-p=NUMBER]\n                    [-tf=\u003ctestCasesFile\u003e] [-tn=\u003ctestCasesNames\u003e]\n      -faf, --failed-and-aborted-file=\u003cfailedTestCases\u003e\n                             Save all failed or aborted tests to this file. The\n                               file can be used as parameter for theCLI option\n                               --tests-file.\n                               Default: ./allFailedOrAborted.txt\n      -h, --help             Display this help message.\n      -np, --no-pdf-report   Do not generate report as PDF.\n      -tf, --tests-file=\u003ctestCasesFile\u003e\n                             The file with tests to run.\n                               Default: ./allTests.txt\n      -tn, --tests-names=\u003ctestCasesNames\u003e\n                             Comma separated list of names to run, for example:\n                               \"verifyUseCaseCertsValid, TslApprovalTestsIT,\n                               TslSignerApprovalTestsIT#checkInitialState\".\n```\n\n### 2. TSL Provider\n\nThe TSL provider is a service that delivers TSLs to the test object.\nThe behavior of this service, such as the content of a TSL offered to the test object, is\nconfigured automatically during the test execution over a REST interface.\nThe TSL provider is implemented as a spring boot tomcat web server and runs as its own process.\n\nThe socket that is runs on is configured as followed:\n\n```yaml\ntslProvider:\n  ipAddressOrFqdn: \"127.0.0.1\"\n  port: 8084\n```\n\nThis configuration is also written to every tsl as the download points in `PointersToOtherTSL`. For\nthis reason, it is crucial to configure it correctly before generating the initial TSL for the test\nobject (see [Initial TSL and Trust Anchor](./README.md#initial-tsl-and-trust-anchor)).\n\nThe TSL provider is started automatically at the configured socket, but it can be started\nindependently. To do so, one has to set `appPath` to `\"externalStartup\"` in the `pkits.yml`. Address\nand port can be passed to the jar via `--server.port=[port]`\nand `--server.address=[ipAddressOrFqdn]`. This way it is possible to run the TSL provider in a\ndifferent environment as the test suite.\n\nThe TSL provider has an open-api interface for documentation at `\u003csocket\u003e/api-docs`.\n\n### 3. OCSP Responder\n\nThe OCSP responder is a service to generate responses to OCSP requests sent by the test object.\nThe behavior of this service is configured over a REST interface and transparent to the user.\nDepending on the tests, the test suite configures it to deliver unsigned OCSP responses, wrong cert\nhashes, and so on.\nSimilar to the TSL provider, it is implemented as a spring boot tomcat web server and runs as its\nown process.\n\nThe socket that is runs on is configured as followed:\n\n```yaml\nocspResponder:\n  ipAddressOrFqdn: \"127.0.0.1\"\n  port: 8083\n```\n\nThis configuration is also written to every tsl as the service supply point of each trust service.\nFor this reason, it is crucial to configure it correctly before generating the initial TSL for the\ntest object (see [Initial TSL and Trust Anchor](./README.md#initial-tsl-and-trust-anchor)).\n\nThe OCSP responder is started automatically at the configured socket, but in can be started\nindependently. To do so, one has to set `appPath` to `\"externalStartup\"` in the `pkits.yml`. Address\nand port can be passed to the jar via `--server.port=[port]`\nand `--server.address=[ipAddressOrFqdn]`. This way it is possible to run the OCSP responder in a\ndifferent environment as the test suite.\n\nExample scripts on how to run the OCSP responder independently for other tasks can be found in the\ndocumentation directory: [ocspResponderExample](docs%2FocspResponderExample) or via the open-api\ninterface: `\u003csocket\u003e/api-docs`.\n\n### 4. Use Case Modules\n\nAt the moment, there are two ways of communicating with a test object. In all scenarios, the test\nobject has to be a server. This means the PKI test suite acts like a client during PKI tests.\n\n#### TLS Client\n\nFor test objects that are more or less a TLS Server, a TSL client implementation is bundled with the\ntest suite. It establishes a TLS handshake to a test object with a given certificate\n(see [configuration](./README.md#configuration)).\nCorresponding to AFOs: `GS-A_4385-01` and `A_17127-01` the TLS handshake will follow the\nspecifications from gemSpec_Krypt with the following parameters:\n\n* TLS Version: 1.2\n* cipher suites used: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 or\n  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256\n* for the test of RSA functionality, we use the following cipher suites:\n  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256\n* for ECDHE either NIST P-256 or P-384 is used\n\n#### Script\n\nA script (shell, batch or other executable program) is started as an own process. A script\ncan be written from every PKI test suite user to communicate with a test object. The test suite\npasses two parameters as command line arguments to any call: `pathToCertificate`\nand `certificatePassword` in this order.\nBe sure to return exit code \"0\" if the communication was successful and \"1\" if it was not. Be\ncareful about the exit code. Thr script solely should only return \"0\" if the use case was\nsuccessful, **not if the script could be executed successful!**\n\n##### Script over SSH\n\nIt is possible to execute a script remotely over ssh. See `sshConfig` section in the configuration\nfile. You have to configure the authentication (password or certificate), files that have to be\ncopied to the remote location and back. As wells as the IP and port of the remote machine.\n\n## Configuration\n\nThe configuration is done in one file: `/config/pkits.yml`. You can find\nexamples in [/docs/config/inttest/](./docs/configs/inttest/). The most important parameters are:\n\n* What is the type of the test object (e.g., KimFachdienst, IntermediaerServer, etc.)?\n* How to reach the test object (i.e., ipAddress and port)?\n\nExample:\n\n```yaml\ntestObject:\n  name: \"Server 0815\"\n  testObjectType: \"IntermediaerServer\"\n  ipAddressOrFqdn: \"127.0.0.1\"\n  port: 8443\n```\n\nFurthermore, the test object must be able to reach the TSL- and OCSP-simulators provided by this\ntest suite.\n\nPaths in the `pkits.yml` are relative to the base directory. Absolute paths can be used as well.\nAll available parameters including a short description can be found\nin [all_pkits_parameters.yml](./docs/all_pkits_parameters.yml). As this is a YAML file remember to\nstrictly follow the syntax.\n\n```text \nRemember: A change of parameters that will change the TSL (i.e. OCSP responder address and port or \nTSL provider address an port) require a new generation of the initial TSL and import to the test \nobject.\n``` \n\nThe TLS-Client used by the testsuite to connect to the testobject supports SNI. SNI is enabled by\ndefault in:  pkits-tls-client/src/main/resources/config.yml.\n\n### Test Data\n\nWe deliver some test data in the directory `./testDataTemplates`. Currently, these test data support\ntests for the following TI products:\n\n| Test object             | testObjectType in pkits.yml | Test data directory         |\n|-------------------------|-----------------------------|-----------------------------|\n| KIM Fachdienst          | KimFachdienst               | kimClientModul              |\n| KIM Fachdienst          | KimFachdienstNist           | kimClientModulNist          |\n| VPN-ZugD Konzentrator   | VpnKonzentrator             | netzkonnektorClient         |\n| VPN-ZugD RegServer      | VpnRegServer                | fachmodulClient             |\n| VSDM Fachdienst         | VsdmFachdienst              | intermediaerClient          |\n| VSDM Intermediär Server | IntermediaerServer          | fachmodulClientIntermediaer |\n| Zentraler/SmartCard IDP | IdpFachdienst               | fachmodulClient             |\n| Zentraler IDP           | IdpEgkFachdienst            | egkClient                   |\n\nUse the new testObjectType KimFachdienstNist instead of KimFachdienst if you want to check if a\nKimFachdienst supports ecc nist certificates correctly.\n\nThese test data are for our own integration tests and can be used for approval tests as well.\nThe test data form an own PKI, hence it is not easy to create them by yourself. If you use your own\ntest data, make sure that issuing certificates are added in\nthe [tsl template](./testDataTemplates/tsl/ECC-RSA_TSL-test.xml) as well.\n\nThe TSLs are generated depending on the boolean parameter tslCryptTypeEccOnly in pkits.yml.\nIf tslCryptTypeEccOnly is true,\na [separate tsl template](./testDataTemplates/tsl/ECC_TSL-test.xml) with only ECC certificates is\nused for TSL generation.\n\n### Initial TSL and Trust Anchor\n\nFor the configuration of the test object, it is necessary to initialize it with a trust space\ncompatible with the test suite.\nFor this, a convenient script is provided by the test suite:\nBy executing `./initialTslAndTa.sh` an initial TSL and the corresponding trust anchor are written to\nthe `./out` directory for manual import into the test object.\nTry `./initialTslAndTa.sh --help` for usage information.\n\nBefore generating this TSL, it is crucial to configure the sockets for\nthe [TSL provider](./README.md#2-tsl-provider) and [OCSP responder](./README.md#3-ocsp-responder)\ncorrectly.\n\nThis TSL contains the TU trust store as well; this means that the test object can be used during the\npki tests by other services as well.\n\n## Test Execution\n\nThe test suite expects a test object that is running and accessible over the configured IP address\nand port (see [Configuration](./README.md#configuration)). Tests are executed via the\nscript `./startApprovalTest.sh`.\nFurthermore, the [OCSP responder](./README.md#3-ocsp-responder)\nand [TSL provider](./README.md#2-tsl-provider) communicate at the configured sockets (if they are\nnot deactivated). Logs are written to the `./out/logs` directory. Afterward a test report is\ngenerated in the `./out/testreport` directory.\n\n### Smoke Test\n\nTo make a quick check if everything is set up correctly, the test object can be reach by\nthe test suite, and to initialize the test suite with the TSL sequence number set in the test\nobject; we implemented a script that runs an initial test: `./checkInitialState.sh`.\nWithin a TSL download by the test object is expected, and afterward, a use case is triggered with a\nvalid certificate.\nOCSP requests are expected and answered correctly as well.\nTherefore, a configured test object has to be up and running and accessible by the testsuite and its\ncomponents.\n\n### Selecting Specific Tests\n\nBesides executing all tests, it is possible to select or exclude specific tests for execution.\nThis is done via the file `allTests.txt`.\nThe file lists test classes `CertificateApprovalTests`, `OcspApprovalTests`,\n`TslApprovalTests`, `TslITSignerApprovalTests`, `TslTaApprovalTests` and all tests defined in\nthe test classes.\nTest classes as well as separate tests can be marked with `+` or `-`.\nTests marked with a `+` will be executed when `./startApprovalTests.sh` is used the next time.\nTests marked with a `-` are excluded from the execution.\nIf a test class is marked with `+` then all tests of the test class are selected for execution,\nexcept those marked with `-`.\nInversely, if a test class is marked with `-` then all tests of the test class are excluded from\nexecution, except those marked with `+`.\nAll failed or aborted tests are saved into file `./allFailedOrAborted.txt` (default name).\nThis file then can be used to run all or selected of the failed or aborted tests.\nRun `java -jar ./bin/pkits-testsuite-exec.jar --help` for more information.\n\n## Testing methodology\n\nOur concept of testing incorporates the following principles:\n\n* An OCSP responder is simulated and the test object is configured to use this instead (over the\n  TSL).\n* A TSL provider is simulated and the test object is configured to use this instead (over the TSL).\n* A use case is triggered that provokes the check of an end-entity certificate.\n\nBoth simulators are configured for each test case and each used certificate individually and\nreset afterward. This means that only during the test execution, the simulators answer requests\nwith a useful response. In between tests, requests are answered with a http 500 error code.\n\nEvery request the test object does to one of the simulators contains the sequence number of the last\ncorrectly processed TSL. This serves as a check to evaluate the trust store in the test object.\n\nMainly, we use two different kinds of test data\n\n1. A default end-entity certificate to trigger a use case for the corresponding test object (e.g., a\n   TLS handshake) signed by a SUB-CA.\n2. An alternative end-entity certificate signed by another SUB-CA. This alternative SUB-CA\n   certificate is not every time in the TSL.\n\nThis way it can be checked if the trust store changed, and if a TSL was processed as expected.\n\nEvery test is independent and all tests can be executed in any order. However, there is one test\nthat is expected to disable the PKI functionality of the test object by importing a TSL which\nexpires a few moments after generation: `verifyExpiredTslInSystem()`. This is why the test suite\nexecutes this test case always at the end.\n\n## Running PKITS Components in Docker Containers\n\nIt is possible to containerize the components of the test suite (OCSP Responder, TSL Provider).\nYou can start them _localy_ as docker compose services. See these configuration files:\n\n* [docker-compose-base.yml](docker-compose-base.yml)\n* [docker-compose-deployLocal.yml](docker-compose-deployLocal.yml)\n\nThe following scripts from directory ./docs/docker/ can be used to build, run and use the container\nimages:\n\n* [docker1_BuildImages.sh](docs%2Fdocker%2Fdocker1_BuildImages.sh)\n* [docker2_StartContainers.sh](docs%2Fdocker%2Fdocker2_StartContainers.sh)\n* [docker3_RunTests.sh](docs%2Fdocker%2Fdocker3_RunTests.sh)\n\nDocker-Desktop 4.21.1 (with Docker Engine 24.0.2 and Docker Compose: v2.19.1) was used for testing\nthis functionality.\n\nMake sure that your particular configuration file (`pkits.yml`) is used by the `docker3_RunTests.sh`\nscript.\n\n## Building the project\n\nThe following command will build the project:\n\n```bash\nmvn clean package \n```\n\nYou can find the binaries in ./bin:\n\n```bash\nls bin\npkits-ocsp-responder-exec.jar\tpkits-sut-server-sim-exec.jar\tpkits-testsuite-exec.jar\tpkits-tsl-provider-exec.jar\n```\n\n#### How are these binaries have been built?\n\nFollowing files are created by the spring-boot-maven-plugin:\n\n```\n./bin/pkits-ocsp-responder-exec.jar\n./bin/pkits-sut-server-sim-exec.jar\n./bin/pkits-tsl-provider-exec.jar \n```\n\nSince version 7.0.1, maven module _pkits-testsuite_ has no longer a parent pom.\n\u003cbr\u003e\n\u003cbr\u003e\nThe maven-shade-plugin is configured in pkits-testsuite/pom.xml to build a fat jar, e.g.,\n_./pkits-testsuite/target/pkits-testsuite-7.0.1-SNAPSHOT.jar_. The copy-rename-maven-plugin copies\nthe\njar file to the _./bin_ directory and renames it to _pkits-testsuite-exec.jar_.\n\nThe other 3 binaries are sprig-boot servers and built with the spring-boot-maven-plugin.\nFinally, the following files are created and copied to the bin directory:\n\n```\n./bin/pkits-ocsp-responder-exec.jar\n./bin/pkits-sut-server-sim-exec.jar\n./bin/pkits-tsl-provider-exec.jar \n./bin/pkits-testsuite-exec.jar\n```\n\n## Versioning\n\nVersions below 1.0.0 are considered incomplete. For every version beyond 1.0.0, every major Version\nwill have a code name naming a chemical element in alphabetical order. If more than one element\nexists with the corresponding letter, the element with lower atomic number is chosen. So the first\n1.0.0 release will be called Aluminum.\n\n## Remark\n\nCryptographic private keys used in this project are solely used in test resources for the purpose of\n(unit) tests. We are fully aware of the content and meaning of the test data. We never publish\nproductive data.\n\n## Know issues\n\n- there are no tests for an invalid keyUsages for the UseCase certificate\n- there are no tests for an invalid extended keyUsage\n\n## License\n\nCopyright 2020-2025 gematik GmbH\n\nApache License, Version 2.0\n\nSee the [LICENSE](./LICENSE) for the specific language governing permissions and limitations under the License\n\n## Additional Notes and Disclaimer from gematik GmbH\n\n1. Copyright notice: Each published work result is accompanied by an explicit statement of the license conditions for use. These are regularly typical conditions in connection with open source or free software. Programs described/provided/linked here are free software, unless otherwise stated.\n2. Permission notice: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the \"Software\"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:\n    1. The copyright notice (Item 1) and the permission notice (Item 2) shall be included in all copies or substantial portions of the Software.\n    2. The software is provided \"as is\" without warranty of any kind, either express or implied, including, but not limited to, the warranties of fitness for a particular purpose, merchantability, and/or non-infringement. The authors or copyright holders shall not be liable in any manner whatsoever for any damages or other claims arising from, out of or in connection with the software or the use or other dealings with the software, whether in an action of contract, tort, or otherwise.\n    3. The software is the result of research and development activities, therefore not necessarily quality assured and without the character of a liable product. For this reason, gematik does not provide any support or other user assistance (unless otherwise stated in individual cases and without justification of a legal obligation). Furthermore, there is no claim to further development and adaptation of the results to a more current state of the art.\n3. Gematik may remove published results temporarily or permanently from the place of publication at any time without prior notice or justification.\n4. Please note: Parts of this code may have been generated using AI-supported technology. Please take this into account, especially when troubleshooting, for security analyses and possible adjustments.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgematik%2Fapp-pkitestsuite","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgematik%2Fapp-pkitestsuite","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgematik%2Fapp-pkitestsuite/lists"}