I am using TFS 2015, I have a Release definition created for my test environment. A task for "PowerShell on Target Machines" has been added. The values are all entered correctly for this such as Machines, Admin Login, Password. HTTPS is the protocol, The Test Certificate checkbox is checked. WinRM listener is already setup on the remote server and working. When I run this task it shows as Rejected.
The error is below:
[error]Connecting to remote server myserver.example.com failed with the following error message : The server certificate on the destination computer (myserver.example.com:5986) has the following errors:
[error]The SSL certificate could not be checked for revocation. The server used to check for revocation might be unreachable. For more information, see the about_Remote_Troubleshooting Help topic.
The TFS agent I am using does not have internet capability. I tried this from another TFS agent that HAS internet capability and it worked.
Does anyone know if the TFS Agent must have internet capability?
Is there a way to skip the revocation checking from the User Interface?
Try to solution here to create and pass a new PSSessionOption object that specifies that all certificate checks should be bypassed.
$sessionOption = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
$session = New-PSSession -ConnectionUri $yourUrl -Credential $credential -Authentication Basic -AllowRedirection -SessionOption $sessionOption
Import-PSSession $session
Related
I have one issue when trying to connect to the LDAP server through code. It works fine when I use admin tool to connect to it.
it works fine when using this admin tool to connect to it.
it doesn't work when I use this code to connect to it, it says
The server could not be contacted. ---> System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
My code:
Using context As DirectoryServices.AccountManagement.PrincipalContext = New DirectoryServices.AccountManagement.PrincipalContext(DirectoryServices.AccountManagement.ContextType.Domain, SingleSignOn.ADDomain, SingleSignOn.ADSecurityGroup, DirectoryServices.AccountManagement.ContextOptions.SecureSocketLayer Or DirectoryServices.AccountManagement.ContextOptions.Negotiate, UserName, Password)
Using foundUser = DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(context, UserName)
Return foundUser IsNot Nothing
End Using
End Using
My question is:
how to set up the code to use version 3?
Thank you in advance for your help/ideas.
Windows needs to trust the SSL certificate, otherwise the connection will fail. Unfortunately the error message doesn't tell you that.
You have a couple options:
Change the certificate being used on the server to a certificate from a trusted root authority. This is the best way to do it, especially if this is a production server.
Tell Windows to trust the self-signed cert. This would have to be done on every computer that will connect. To do this, use the PowerShell script in this answer to download the certificate (change the URL to match your server). This will give you a .cer file. Then follow the instructions here to import it on the computer that you are running this code on. In that article, start at the heading "To start the certificate import process through Microsoft Management Console (MMC)". In step 4, you have the option to import it for the current user only, or for the whole computer (which requires local admin rights).
When installing a self-signed certificate for use in VPN authentication, I ran into an interesting problem: the VPN would successfully authenticate for some time after the installation, but after a reboot I would start getting the following message:
Error 798: A certificate could not be found that can be used with this Extensible Authentication Protocol
(I actually wrote a full question while I was debugging this, when I didn't know the cause, which you can find here: Some clients can only authenticate to VPN when connecting as Administrator. But to summarize: after a reboot users would start getting this message and from that point the connection could only be established by connecting as Administrator [i.e. running rasphone or rasdial as Administrator].)
It's worth noting that redoing the installation would make the connection work again until the next reboot.
What ended up being important- and the reason this belongs on StackOverflow and not another site- is that I was installing this certificate via code. I had written a program to automate the VPN installation; it did a number of things, one of which was installing the client certificate for authentication. Here is an abbreviated version of the certificate installation code:
Dim Certs As New X509Certificate2Collection()
Certs.Import(PfxFileName, Password, X509KeyStorageFlags.PersistKeySet)
Dim ClientCert, IssuerCert As X509Certificate2
If Certs(0).HasPrivateKey Then
ClientCert = Certs(0)
IssuerCert = Certs(1)
Else
ClientCert = Certs(1)
IssuerCert = Certs(0)
End If
Using Store As New X509Store(StoreName.Root, StoreLocation.LocalMachine)
Store.Open(OpenFlags.ReadWrite)
Store.Add(IssuerCert)
End Using
Using Store As New X509Store(StoreName.My, StoreLocation.CurrentUser)
Store.Open(OpenFlags.ReadWrite)
Store.Add(ClientCert)
End Using
My pfx files always had two certificates: the client's with its private key, and the root without one. The root certificate needed to go in cert:/LocalMachine/Root and the client certificate needed to go in cert:/CurrentUser/My.
Using the above code, the previously stated problem would result.
Using the process of elimination, I ran each part of my custom installation software and found that it was the re-installtion of the certificate alone (using the code above) that caused the connection to temporarily start working again. I then tried installing the certificate manually (by double-clicking the pfx file and using the dialog box).
I found that when I installed the certificate manually, the VPN connection worked stabily, but when I installed it via the previous code, it only worked until my next reboot. This indicated to me that there must be some difference between what my code was doing, and what the dialog box was doing.
And then it hit me: my program is running as Administrator. But the dialog box for adding a certificate to the CurrentUser store never gives a UAC prompt, so it's running under my normal user context.
Now, there are parts of my program that do need to run as Administrator, so I had to rework the whole thing to use two processes (one admin and one non-admin) to do different parts of the installation. I won't get into that here, but once I had it all working I tried running the following part of the code as a non-admin:
Using Store As New X509Store(StoreName.My, StoreLocation.CurrentUser)
Store.Open(OpenFlags.ReadWrite)
Store.Add(ClientCert)
End Using
And it worked! As long as I added the client certificate to the CurrentUser store as a non-admin, the VPN connection was able to consistantly connect across reboots.
I still don't quite understand why running the code as Administrator causes the problems it does. The certificate does appear in the cert:/CurrentUser/My, but it just doesn't work once it's there. Maybe it has something to do with some hidden permissions on the associated private key? That might explain why connecting as Administrator always worked, but not why connecting as a non-admin worked until a reboot occurred.
I am new to WebSphere (as you can tell by my dated username) and I have made a mistake. While trying to address security concerns in my organization I deleted the self-signed certificates in WebSphere. This seems to have caused the Integrated Solutions Console to break. Our application hosted in WebSphere is still working fine.
Is there a way to use a Jython or Jacl script to recreate these certs and configure them properly? Or is there perhaps another way to get access to the Console?
The web browser (IE) complains about TLS errors when trying to load the Console page.
You can create a new certificate using the createSelfSignedCertificate command from wsadmin. You'll have to run wsadmin unconnected to the server.
So roughly
start wsadmin eg.
wsadmin -conntype none
Then run the createSelfSignedCertificate task. The keystore is likely NodeDefaultKeyStore if you are on a stand alone app server or CellDefaultKeyStore if you are on a ND environment. You have to provide a management scope if running unconnected. You can get the list or management scope with the listManagementScopes command. Fill in your hostname for the certificateCommonName parameter.
eg.
to get the list of management scopes
wsadmin> AdminTask.listManagementScopes()
to create a self-signed certificate
AdminTask.createSelfSignedCertificate('[-keyStoreName -keyStoreScope -certificateAlias -certificateCommonName -certificateOrganization ibm -certificateState us ]')
to save the changes
AdminConfig.save()
If you just need to get into the console you can disable security in /config/cells/../security.xml
Just set "enabled=false" and restart the server. Using the console to create a new certificate should be easier than using wsadmin
I'm trying to setup SSO using OWin and Thinktecture Identity Server but I am not having any luck getting the SSL certificate to work. At least I think that's the problem. All works fine when I'm in visual studio, but if I try to use IIS on my machine it gives me the error "The remote certificate is invalid according to the validation procedure". I've also tried using IIS as the client treat the instance running in visual studio as the token authority but I still get the same error. Anyone have any ideas on what I'm doing wrong?
In my case I was just trying to work through the samples (for ID3v2) and getting the cert errors running locally. Since some samples even do self hosting via owin I'm not even sure where it's getting the certs for host side??
Anyway my fix was to copy the cert to the Trusted Root:
Windows => Start => run MMC.EXE
File=> "Add/Remove Snap-In..." => Certificates
Use Computer Account => Local computer => Finish => Ok
Go under Personal / Certificates
Right click "localhost", Select Copy
Paste to "Trusted Root Certificate Authorities"
Done. Enjoy.
After spending a lot of time for me the solution was pretty simple
I just opened the Certmgr.msc ---> deleted the localhost certificate from the Trusted Root certification authorities.
Then opened my solution (after I had run the identity sever)
clicked run the visual studio asked fro me if I want generate new certificate to iis express (ssl),
I had clicked yes and then it started to work properly:)
You need to add whatever certificate IIS is using to your Trusted Root Certification Authorities store on your local computer.
That can be caused by bad configuration on a previous certifications (sometimes can happen when you disagree to install a certification) :
Windows Start and open Certmgr.msc
Under Personnel/Certificats, find all localhost certificats and delete them
Same thing to do under Trusted Root Certification, and then close.
Start your application, you will get an exception.
Open the Package Manager Console and excute: dotnet dev-certs https --trust
Restart your application, normally you have a valid certificat now.
Adding certificate to Trusted People store should be enough according to readme file in examples provided by the authors.
In a production scenario it should be better because Root store is for CAs and when you add something there that authority is not only trusted, but any certificate signed by it is automatically trusted.
You can check this an further details from the microsoft reference. An extract of the 2 store short description:
Root: Certificate store for trusted root certification authorities (CAs).
TrustedPeople: Certificate store for directly trusted people and resources.
P.S: I tested it an it works. In my scenario I have IS on machine A and a set of web applications using IS on machine A and B. IIS certificate on machine B is different from the one used in A and by IS, but I just added it on machine B Trusted People store and the "certificate error" disappeard.
Some times it doesn't work though the above settings were done and you have given the URL as "https://localhost", instead give the URL as "https://MachineName".
i.e machine name should match certificate's "issue to" value
For .Net Core change TrustServerCertificate=False to TrustServerCertificate=True and that will solve your problem like I have it below.
"DataConnect": "Server=tcp:127.0.0.1,1433;Initial Catalog=dbName;Persist Security Info=False;User ID=username;Password=password;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=True;Connection Timeout=30;"
We are upgrading the server from Windows 2003 to 2008. As part of the process, I need to configure a port with a SSL certificate. When I ran the following command:
netsh http add sslcert ipport=1.2.3.4:8000 certhash=certificatehash appid={someGUID}
I got the following error:
SSL Certificate add failed, Error:
1312 A specified logon session does
not exist. It may already have been
terminated.
When running the command prompt with an administrator does not resolve the issue. Notice that I did not run into this issue on Windows 2003 (using httpcfg) and that things work well there.
Has anyone encountered this issue? Thanks.
the 1312 shows up at several occasions. aside from typos on the commandline, the other most common are:
- the certificate is not in your certificate store at all (check with MMC and 'certificates' snap-in)
- the certificate is in the wrong store: it should be in the store of 'local computer' not 'local user' (remember to choose proper account when activating the snapin inside the MMC)
- the certificate doesnt contain a Private Key (open the certificate and check whether it contains only public, or both keys)
I've spent over 1.5 hours before I found out that I've had generated a certificate succesfully, but misplaced some switches and it got written to a file without the private key:)
Are you running from an elevated command prompt (not just as an admin)?. There's an open source GUI tool that drives the HTTP config APIs directly- I use it on 2008 R2 with no trouble (it auto-requests elevation via UAC). I've had mixed results with netsh/httpcfg. This one always works for me (and it behaves the same everywhere).