in the last recent days i was handle with iis permissions issue,
while trying to send http request from iis application (windows server 2012 r2 IIS 8.5) - I get an exception 401 unauthorized. (SSL Client Certificate Authentication)
when i try to simulate it with different OS (2008 R2 IIS 7.5) - I get 200 OK & everything goes as expected.
after a little research we reached to obtain a local admin to the application pool user to check if the following scenario related to a permissions field .
and guess what? it's works as we verified - application pool user identity needs...
a Great post about Migrating Certification Authority Hashing Algorithm from SHA1 to SHA2 , by Senior Support Escalation Engineer Rob Greene :
Generating Key for Secure Store Service Application
Open Sharepoint Management Shell ,Run the following commands to export:
$stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigninCertificate
$stsCert.Export(“cert”) | Set-Content –encoding byte SP_STS.cer
2. The file SP_STS.cer is created in the same directory from where the command was executed. C:\Users\OWNUser
3. Copy SPS_STS.cer to the directory FASTSearch to the FAST Search Server for SharePoint node and copy the file to from C:\Users\OWNuser to c:\FASTSearch\ .
4. Import Certificate to publishing farm
Open Windows PowerShell and Run the following commands:
Type: cd c:\FASTSearch\installer\scripts
.\InstallSTSCertificateForClaims.ps1 certPath c:\FASTSearch\MOSS_STS.cer
4.copy the pfx file from c:\FASTSearch\data\data_security\cert to the SharePoint Server, in this case, just to the root of c:\
You will also...
Yesterday I came across issue problem of a permissions on
Third-Party Root Certification Authorities store with an Access Denied .
The following exhibiting the issue problem and the resolution:
1. Event 4110, CAPI2
Failed to add certificate to Third-Party Root Certification Authorities store with error: Access is denied.
2. Process Monitor = Capture Access Denied on Registry:
3. Resolution - Check for "NT SERVICE\CryptSvc" Group existing:
Poodle attack known by his ability to exploit a SSL Vulnerability , the problem related to the CBC Encryption scheme as implemented in the SSL 3 protocol,
To be able to fix that from being attack we need to disabling the SSL V3 on the local Machine:
If not exist, create the SSL 3.0 Key
Finally Restart the server
In the last Recent days I've handle with CSP issue in ADFS environment
When i got this error message at the end of the ADFS wizard:
The certificates with the CNG private key are not supported. Use a certificate based on a key pair generated by a legacy Cryptographic Service Provider
The problem occurred because of "next generation" template's CSP certificate.
Creating new template (2003) and pick for :
Microsoft DH SChannel Cryptographic Provider
Microsoft RSA SChannel Cryptographic Provider
As mentioned here:
Creating new certificate and import it to ADFS's local machine store.
Try running ADFS's Wizard again.
In the last recent days i've handle with permissions to certificate template issue,with this message error type:
The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
You do not have permission to request this type of certificate
This issue caused by an incorrect Certificate Template permission .
Solution: grant Authenticated users Enroll permission:
1.Open MMC, click File menu, choose Add/Remove Snap-in, choose Certificate Templates, click OK.
2.Double-click the certificate template you used to request certificate, go forward to Security tab, selected Authenticated users, click Enroll option. Click OK.
3.Open CA console, stop CA service and...
As You probably all know , certificates placed under MMC Current User/Local Machine Stores,
The physical registry of the certificates point to the Thumbprint certificate itself.
Recovering an Archived Private Key with the following steps:
1. The Certificate Manager should:
a. Identifies the certificate
b. Determines the KRAs
c. Extracts the PKCS #7 blob
2. The KRA:
a. Recover the private key
b. Securely transports the PKCS #12 file to the user
Imports the recovered private key
By default, LDAP communications between client and server applications are not encrypted. This means that it would be possible to use a network monitoring device or software and view the communications traveling between LDAP client and server computers. This is especially problematic when an LDAP simple bind is used because credentials (username and password) is passed over the network unencrypted. This could quickly lead to the compromise of credentials.
For more details follow the link below: