You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/100-General/10-Changelog.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ Released closed milestones can be found on [GitHub](https://github.com/Icinga/ic
18
18
### Bugfixes
19
19
20
20
*[#718](https://github.com/Icinga/icinga-powershell-framework/issues/718) Fixes Icinga repository JSON validator to report the correct state of the validation status, in case the JSON is not valid
21
-
21
+
*[#725](https://github.com/Icinga/icinga-powershell-framework/pull/725) Fixes Icinga for Windows certificate handling by keeping the .pfx file on the system as created, without using the certificate store. Also fixes handling for providing thumbprints for certificates, which are now loaded directly from the certificate store by also providing a new filter mechanic to fetch the proper certificates from the store
Copy file name to clipboardExpand all lines: doc/knowledgebase/IWKB000018.md
+70-2Lines changed: 70 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -26,8 +26,76 @@ Internal
26
26
27
27
## Reason
28
28
29
-
This message happens in case the user assigned to run the Icinga for Windows has no sufficient permissions to access the `icingaforwindows.pfx` certificate file or has no permissions to read the private key from the certificate file.
29
+
This message happens in case the user assigned to run Icinga for Windows has insufficient permissions to access the given certificates private key. Most commonly, this will happen when Icinga for Windows will run as `NT Authority\NetworkService` while a certificate is loaded from the certificate store.
30
30
31
31
## Solution
32
32
33
-
To resolve this issue, you will either have to use [JEA-Profiles](../130-JEA/01-JEA-Profiles.md) or use a different user having enough permissions to access private key to the file. In general, only `LocalSystem` or `Administrators` have access to this key, which is why we highly recommend the use of JEA.
33
+
### Use JEA
34
+
35
+
Regardless if you are using certificates from the certificate store or the `icingaforwindows.pfx`, we recommend using [JEA-Profiles](../130-JEA/01-JEA-Profiles.md) with a dedicated user like `icinga`. This resolves most permission issues, increases security and is easier to manage.
36
+
37
+
### Use icingaforwindows.pfx
38
+
39
+
The easiest solution besides using [JEA](../130-JEA/01-JEA-Profiles.md) would to configure the Icinga for Windows background daemon to look for the default certificate to load while starting the REST-Api. This certificate is the `icingaforwindows.pfx` which is by default located at
This certificate is generated automatically based on your `Icinga Agent certificate` on the machine during the first installation of Icinga for Windows and updated every day at 1:00 am by a scheduled task in the background. In case the certificate is not present and you want to use it or renew the certificate, you can generate it with the following command
46
+
47
+
```powershell
48
+
Start-IcingaWindowsScheduledTaskRenewCertificate;
49
+
```
50
+
51
+
This will generate the certificate and ensure it is present on the system. If you reconfigured your API to use a specific certificate from the cert store, you can restore the default behavior with
Afterwards simply restart Icinga for Windows and the API should be working properly
58
+
59
+
```powershell
60
+
Restart-IcingaForWindows;
61
+
```
62
+
63
+
### Grant permission to user for the private key
64
+
65
+
If you want to use a certificate stored inside the certificate store and you receive the above error message, you will have to make sure the corresponding user has access to the `private key` of the certificate. By using [JEA](../130-JEA/01-JEA-Profiles.md), you can skip this part as long as it is not the `NT Authority\NetworkService` user you are having problems with.
66
+
67
+
Please make sure as well, that your certificates are stored somewhere in the `LocalMachine` store and **not** in the `CurrentUser` Space.
68
+
69
+
To change the permission for the private key of the certificate, proceed as follow
70
+
71
+
1. Hint `Windows Key + R`
72
+
2. Enter `mmc` into the Run dialog and hit enter (confirm a possible UAC prompt)
73
+
3. Inside the mmc, on the top left click on `File` -> `Add/Remove Snap-In`
74
+
4. Inside the new dialog look for `Certificates` and click the `Add` button in the middle
75
+
5. A new window `Certificates snap-in` will pop up
76
+
6. Select `Computer account` and click `Next`
77
+
7. Use the `Local computer` and click `Finish` and on the remaining Window `Ok`
78
+
79
+
Now you need to navigate to the location on where your certificate is installed to. In our example, we assume it is installed in the `Personal` space
In the new window, click the `Add...` button and add the `NT Authority\NetworkService` user to the list of users having access to the private key. Most commonly you have to simply write `NETWORK SERVICE` into the prompt. Change this user for the ony applying to your use case.
0 commit comments