Trusting the self signed certificate to enable SSL on dotnet core #227

New Issue

Closed

opened 2025-12-29 08:24:22 +01:00 by adam · 8 comments

adam commented 2025-12-29 08:24:22 +01:00

Owner

Copy Link

Originally created by @alastairtree on GitHub (Nov 27, 2019).

In the following code (tested running on dotnet core 3.0/2.2/2.1) I want to start a stub server with SSL enabled and then call it, and for that https call to be trusted and allowed. However, the self signed cert issued by wiremock is not trusted and the call fails with AuthenticationException: The remote certificate is invalid according to the validation procedure.

I assumed that running on port 5001 would use the self signed kestral dev certs installed by default by the dotnet cli and so be trusted but I think not based on the below failing.

What is the easiest "out of the box" way to get SSL to work like in the example below?
Or is there a way to get wiremock to use a self siged cert I already trust or to get the current certificate out of the server so I can validate it easily in the client?

    class Program
    {
        static async Task Main(string[] args)
        {
            var server1 = FluentMockServer.Start(port:5001, ssl: true);
            server1.Given(Request.Create().UsingGet().WithPath("/example"))
                .RespondWith(Response.Create()
                    .WithStatusCode(200)
                    .WithBodyAsJson( new
                {
                    Message = "Hello world"
                }));

            var client = new HttpClient()
            {
                BaseAddress = new Uri(server1.Urls.Single())
            };
            
            var json = await client.GetAsync("example");

            Console.WriteLine(json);
            Console.WriteLine(await json.Content.ReadAsStringAsync());

            Console.ReadLine();
        }
    }

Originally created by @alastairtree on GitHub (Nov 27, 2019). In the following code (tested running on dotnet core 3.0/2.2/2.1) I want to start a stub server with SSL enabled and then call it, and for that https call to be trusted and allowed. However, the self signed cert issued by wiremock is not trusted and the call fails with `AuthenticationException: The remote certificate is invalid according to the validation procedure`. I assumed that running on port 5001 would use the self signed kestral dev certs installed by default by the dotnet cli and so be trusted but I think not based on the below failing. What is the easiest "out of the box" way to get SSL to work like in the example below? Or is there a way to get wiremock to use a self siged cert I already trust or to get the current certificate out of the server so I can validate it easily in the client? ```csharp class Program { static async Task Main(string[] args) { var server1 = FluentMockServer.Start(port:5001, ssl: true); server1.Given(Request.Create().UsingGet().WithPath("/example")) .RespondWith(Response.Create() .WithStatusCode(200) .WithBodyAsJson( new { Message = "Hello world" })); var client = new HttpClient() { BaseAddress = new Uri(server1.Urls.Single()) }; var json = await client.GetAsync("example"); Console.WriteLine(json); Console.WriteLine(await json.Content.ReadAsStringAsync()); Console.ReadLine(); } } ```

adam added the bug label 2025-12-29 08:24:22 +01:00

adam closed this issue 2025-12-29 08:24:22 +01:00

adam commented 2025-12-29 08:24:23 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Nov 27, 2019):

Do you only have this issue in .net core 3?

@StefH commented on GitHub (Nov 27, 2019): Do you only have this issue in .net core 3?

adam commented 2025-12-29 08:24:23 +01:00

Author

Owner

Copy Link

@alastairtree commented on GitHub (Nov 27, 2019):

No it appears in core 2.1/2.2 also.

I think it because you are passing in a hardcoded cert PublicCertificateHelper.GetX509Certificate2() in AspNetCoreSelfHost to kestrel. If you leave the certificate blank and run on 5001 then kestral should load with the default development certificate if you have already installed it (installed with dotnet dev-certs https --trust). That way it would work with trusted SSL out of the box if you run it under core with the cli.

Alternatively you could make the certificate public so that you can choose to trust it like this:

        var _clientHandler = new HttpClientHandler();
        var trustedWiremockCert = PublicCertificateHelper.GetX509Certificate2();
        _clientHandler.ClientCertificates.Add(trustedWiremockCert);
        _clientHandler.ClientCertificateOptions = ClientCertificateOption.Manual;
        var client = new HttpClient(_clientHandler)

All of the above is untested but might work in theory

@alastairtree commented on GitHub (Nov 27, 2019): No it appears in core 2.1/2.2 also. I think it because you are passing in a hardcoded cert `PublicCertificateHelper.GetX509Certificate2()` in `AspNetCoreSelfHost` to kestrel. If you leave the certificate blank and run on 5001 then kestral should load with the default development certificate if you have already installed it (installed with `dotnet dev-certs https --trust`). That way it would work with trusted SSL out of the box if you run it under core with the cli. Alternatively you could make the certificate public so that you can choose to trust it like this: var _clientHandler = new HttpClientHandler(); var trustedWiremockCert = PublicCertificateHelper.GetX509Certificate2(); _clientHandler.ClientCertificates.Add(trustedWiremockCert); _clientHandler.ClientCertificateOptions = ClientCertificateOption.Manual; var client = new HttpClient(_clientHandler) All of the above is untested but might work in theory

adam commented 2025-12-29 08:24:23 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Nov 28, 2019):

I see your point.

Currently I'm using a self-signed certificate in WireMock when using netstandard or net core.

But, I can't remember why I created an own self-signed, and not just use the default development certificate like https://www.hanselman.com/blog/DevelopingLocallyWithASPNETCoreUnderHTTPSSSLAndSelfSignedCerts.aspx.

So I think I need to update the current code to make it an option:

1. Use the current internal self-signed
2. Use the default development certificate
3. Let the developer/user from WireMock provide his own certificate.

What do you think?

@StefH commented on GitHub (Nov 28, 2019): I see your point. Currently I'm using a self-signed certificate in WireMock when using netstandard or net core. But, I can't remember why I created an own self-signed, and not just use the default development certificate like https://www.hanselman.com/blog/DevelopingLocallyWithASPNETCoreUnderHTTPSSSLAndSelfSignedCerts.aspx. So I think I need to update the current code to make it an option: 1. Use the current internal self-signed 2. Use the default development certificate 3. Let the developer/user from WireMock provide his own certificate. What do you think?

adam commented 2025-12-29 08:24:23 +01:00

Author

Owner

Copy Link

@alastairtree commented on GitHub (Nov 28, 2019):

My preference would be to follow the same defaults as kestrel, as that is what developers are most likely to be familiar with. This means the default should be to leave the cert blank and pick up the dev cert, and to host on 5001 by default if SSL is enabled and no port is specified. That way most users will find SSL just works and follows the idioms of regular aspnet development. Then I suggest we also allow the user to pass an Action<KestrelServerOptions> options param on the settings/server setup somewhere and apply this action/callback when calling into kestral. This will allow the user to directly configure Kestral themselves. That way they have full scope to pass filename/password or custom certificate or any other setup if they need to. something like this:

wireMockSettings.ConfigureKestrel(serverOptions =>
{
 //do some custom config here. 
}

We then hold the Action<KestrelServerOptions> value in a property somewhere and apply it at the right time during kestrel setup.

The options aspnet core/Kestrel allows are detailed at
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.0#configurehttpsdefaultsactionhttpsconnectionadapteroptions

If you then make PublicCertificateHelper.GetX509Certificate2() public, (and perhaps mark obsolete?) it would be easy for a user to pass something like this to maintain the existing behaviour if they really need to:

wireMockSettings.ConfigureKestrel(serverOptions =>
{
    serverOptions.ConfigureHttpsDefaults(listenOptions =>
    {
        listenOptions.ServerCertificate = PublicCertificateHelper.GetX509Certificate2();
    });
});

Although this seems like a breaking change, at the moment I can't see any way a way for wiremock users on dotnet core to use HTTPS without disabling all certificate validation anyway, so those users would not be affected.

@alastairtree commented on GitHub (Nov 28, 2019): My preference would be to follow the same defaults as kestrel, as that is what developers are most likely to be familiar with. This means the default should be to leave the cert blank and pick up the dev cert, and to host on 5001 by default if SSL is enabled and no port is specified. That way most users will find SSL just works and follows the idioms of regular aspnet development. Then I suggest we also allow the user to pass an `Action<KestrelServerOptions> options` param on the settings/server setup somewhere and apply this action/callback when calling into kestral. This will allow the user to directly configure Kestral themselves. That way they have full scope to pass filename/password or custom certificate or any other setup if they need to. something like this: ``` c# wireMockSettings.ConfigureKestrel(serverOptions => { //do some custom config here. } ``` We then hold the `Action<KestrelServerOptions>` value in a property somewhere and apply it at the right time during kestrel setup. The options aspnet core/Kestrel allows are detailed at https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.0#configurehttpsdefaultsactionhttpsconnectionadapteroptions If you then make `PublicCertificateHelper.GetX509Certificate2()` public, (and perhaps mark obsolete?) it would be easy for a user to pass something like this to maintain the existing behaviour if they really need to: ``` c# wireMockSettings.ConfigureKestrel(serverOptions => { serverOptions.ConfigureHttpsDefaults(listenOptions => { listenOptions.ServerCertificate = PublicCertificateHelper.GetX509Certificate2(); }); }); ``` Although this seems like a breaking change, at the moment I can't see any way a way for wiremock users on dotnet core to use HTTPS without disabling all certificate validation anyway, so those users would not be affected.

adam commented 2025-12-29 08:24:23 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Nov 29, 2019):

I'll follow default development certificate for .NET Core 2.x for now.

Preview version from MyGet is WireMock.Net.1.0.37-ci-12243 and I'll create a new NuGet this weekend.

@StefH commented on GitHub (Nov 29, 2019): I'll follow default development certificate for .NET Core 2.x for now. Preview version from MyGet is `WireMock.Net.1.0.37-ci-12243` and I'll create a new NuGet this weekend.

adam commented 2025-12-29 08:24:23 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Dec 26, 2019):

@alastairtree Did this work for you?

@StefH commented on GitHub (Dec 26, 2019): @alastairtree Did this work for you?

adam commented 2025-12-29 08:24:24 +01:00

Author

Owner

Copy Link

@alastairtree commented on GitHub (Dec 26, 2019):

Yes it did, Thanks!

@alastairtree commented on GitHub (Dec 26, 2019): Yes it did, Thanks!

adam commented 2025-12-29 08:24:24 +01:00

Author

Owner

Copy Link

@StefH commented on GitHub (Mar 12, 2020):

Closing issue

@StefH commented on GitHub (Mar 12, 2020): Closing issue

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

master

mime-part-matcher

version-2.x

MappingSerializer

1341-mapping-json

stef-aspire-tests-updates

bug/973-TinyMapper

bug/1149-AppendGuidToSavedMappingFile

feature/1150-DockerImageVersion

61

stef-1108

stef-1097

stef-1083-MessageOptions_Type_Conflict

stef-1062-logger

stef-IgnoreOpenApiErrors

stef-928-TypeLoadException-FluentAssertions-net472

nunit

stef-849

stef-847-regex-questionmark

http_verb

WireMockServerContext

webapp

ai

CommandLineArgumentsParser

1.23.0

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.0

1.15.0

1.14.0

1.13.0

1.12.0

1.11.2

1.11.0

1.10.1

1.10.0

1.9.1

1.9.0

1.8.18

1.8.17

1.8.16

1.8.15

1.8.14

1.8.13

1.8.12

1.8.11

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.3

1.8.2

1.8.1

1.8.0

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.12

1.6.11

1.6.10

1.6.9

1.6.8

1.6.7

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.62

1.5.61

1.5.60

1.5.59

1.5.58

1.5.57

1.5.56

1.5.55

1.5.54

1.5.53

1.5.52

1.5.51

1.5.50

1.5.49

1.5.48

1.5.47

1.5.46

1.5.45

1.5.44

1.5.43

1.5.42

1.5.41

1.5.40

1.5.39

1.5.38

1.5.37

1.5.36

1.5.35

1.5.34

1.5.33

1.5.32

1.5.31

1.5.30

1.5.29

1.5.28

1.5.27

1.5.26

1.5.25

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.43

1.4.42

1.4.41

1.4.40

1.4.39

1.4.38

1.4.37

1.4.36

1.4.35

1.4.34

1.4.33

1.4.32

1.4.31

1.4.30

1.4.29

1.4.28

1.4.27

1.4.26

1.4.25

1.4.24

1.4.23

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.10

1.3.9

1.3.8

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11.0

1.2.10

1.2.9.0

1.2.8.0

1.2.7.0

1.2.6.0

1.2.5.0

1.2.4.0

1.2.3.0

1.2.2.0

1.2.1.0

1.2.0.0

1.1.10

1.1.9.0

1.1.8.0

1.1.7.0

1.1.6.0

1.1.5.0

1.1.3.0

1.1.2.0

1.1.1.0

1.1.0.0

1.0.43.0

1.0.42.0

1.0.41.0

1.0.40.0

1.0.39.0

1.0.38.0

1.0.37.0

1.0.36.0

1.0.35.0

1.0.34.0

1.0.33.0

1.0.32.0

1.0.31.0

1.0.29.0

1.0.28.0

1.0.25.0

1.0.24.0

1.0.23.0

1.0.22.0

1.0.21.0

1.0.20.0

1.0.19.0

1.0.18.0

1.0.17.0

1.0.16.0

1.0.15.0

1.0.14.0

1.0.13.0

1.0.12.0

1.0.11.0

1.0.10.0

1.0.9.0

1.0.8.0

1.0.7.0

1.0.6.1

1.0.6

1.0.5

1.0.4.21

1.0.4.20

1.0.4.19

1.0.4.18

1.0.4.17

1.0.4.16

1.0.4.15

1.0.4.14

1.0.4.13

1.0.4.12

1.0.4.11

1.0.4.10

1.0.4.9

1.0.4.8

1.0.4.7

1.0.4.6

1.0.4.5

1.0.4.4

1.0.4.3

1.0.4.2

1.0.4.1

1.0.4.0

1.0.3.20

1.0.3.19

1.0.3.18

1.0.3.17

1.0.3.16

1.0.3.15

1.0.3.14

1.0.3.13

1.0.3.12

1.0.3.11

1.0.3.10

1.0.3.9

1.0.3.8

1.0.3.7

1.0.3.6

1.0.3.5

1.0.3.4

1.0.3.3

1.0.3.2

1.0.3.1

1.0.3.0

1.0.2.13

1.0.2.12

1.0.2.11

1.0.2.10

1.0.2.9

1.0.2.8

1.0.2.7

1.0.2.6

1.0.2.5

1.0.2.4

1.0.2.1

1.0.2.0

1.0.1.5

1.0.1.3

1.0.1.2

1.0.1.1

1.0.0.0

Labels

Clear labels

bug

bug

doc

doc

duplicate

feature

feature

invalid

pull-request

Mirrored from GitHub Pull Request

question

wontfix

No Label bug

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

adam

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/WireMock.Net#227