We already have a common module to add certificates here:
https://github.com/PowerShell/PowerShell/blob/master/test/powershell/Modules/Microsoft.PowerShell.Security/certificateCommon.psm1

We shouldn't duplicate the code.

@TravisEz13 I tested with that. But the cert in New-GoodCertificate does not contain the proper key usage to be used for SSL/TLS Auth. It is issued for only Document Encryption. I was afraid if I change the cert in certificateCommon.psm1 I might be break tests that depend on that restriction. Thus, I added a new function in WebCmdlets.Tests.ps1 instead. What do you suggest?

Move the module to a common location and add your function to it, with descriptions of each cert (at least what you learned.) At the minimum, file an issue that this work needs to be done to avoid future duplication of effort. Even then, I would suggest adding the comments to each now.

@markekraus Can you address this feedback please?

@adityapatwardhan I did here and with 305c048. Was that insufficient?

Sorry missed that.

I suggest you check to see if you can mock using WebRequest.RegisterPrefix instead of relying on an external site. We find external sites make the tests unreliable. See #2504

Especially introducing a dependency on a new site.

I agree. But I lack the skill to implement this. I would need guidance or assistance.

It seems @SteveL-MSFT have plans to add HTTPS support in our test HttpListener.psm1.
I like it more than adding hook.

@iSazonov awesome. that would be better. It will probably also need some way to ensure the client authentication cert is received by the listener too or to enforce certificate authentication on the listener so it can fail if one is not provided.

@dantraMSFT I'm not entirely sure WebRequest.RegisterPrefix will work on Core. Unless I'm missing something, I don't think it would affect anything being done with the new classes under System.Net.Http in use in Core. I was able to make a mockup with it, but it only works on Windows PowerShell (tested on 5.1). Unless I'm going totally in the wrong direction?

I'm open to that, but I don't think we should be regularly
running the tests without doing one one the other either:

1. Get explicit permission to use the site for automated tested
2. find an alternative
3. mark the tests a pending until the issue is resolved.

@TravisEz13 Ok. Let me look into docker/aspnetcore. If I can't make heads or tails of it, I will mark the test pending and create an issue.

On the docker topic, would it be best to include a subfolder with a dockerfile and whatever assets are needed, have the test code run the docker build, run the container, do the relevant test, and tear down the container? Or or there some better way to do that? I imagine that could be a rather slow test.

It would definitely make these slow tests and I think feature tests. There are some tests that use docker here: https://github.com/PowerShell/PowerShell/tree/master/test/docker/networktest But those tests, are meant to be a different suite.

I think @iSazonov might be right. I think option 3 might be the best option. Mark the tests as pending, and file an issue. If you are still willing to work on trying to fix the tests, I'd love to work with you. Assuming @adityapatwardhan (the maintainer for the PR) agrees.

Oh, and add a comment with the issue number saying why the tests are marked pending.

@TravisEz13 Issue #4609 created, tests set to pending, and comments added. I'm still interested in figuring this out, I'm just unsure of the time it will take me to get up to speed on aspnetcore enough to do this.

Suggest explicitly setting ClientCertificateOptions to ClientCertificateOption.Manual.

added.

I think we need some explicit statement linked to the site that we can use the site in our tests.