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: docs/architecture/dapr-for-net-developers/observability.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -195,7 +195,7 @@ spec:
195
195
196
196
##### Inspect the telemetry in Zipkin
197
197
198
-
Once the application is started, the Dapr sidecars will emit telemetry to the Zipkin server. To inspect this telemetry, point a web-browser to <http://localhost:32411>. You'll see the Zipkin web front end:
198
+
Once the application is started, the Dapr sidecars will emit telemetry to the Zipkin server. To inspect this telemetry, point a web-browser to `http://localhost:32411`. You'll see the Zipkin web front end:
Copy file name to clipboardExpand all lines: docs/architecture/microservices/multi-container-microservice-net-applications/implement-api-gateways-with-ocelot.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -394,7 +394,7 @@ In the case of the "Marketing" business area and microservices, it is a simple u
394
394
395
395
### Authentication and authorization in Ocelot API Gateways
396
396
397
-
In an Ocelot API Gateway you can sit the authentication service, such as an ASP.NET Core Web API service using [IdentityServer](https://identityserver.io/) providing the auth token, either out or inside the API Gateway.
397
+
In an Ocelot API Gateway, you can sit the authentication service, such as an ASP.NET Core Web API service using [IdentityServer](../../cloud-native/identity-server.md) providing the auth token, either out or inside the API Gateway.
398
398
399
399
Since eShopOnContainers is using multiple API Gateways with boundaries based on BFF and business areas, the Identity/Auth service is left out of the API Gateways, as highlighted in yellow in the following diagram.
| Jobs | NuGet [0.3.2-beta](https://www.nuget.org/packages/Microsoft.Azure.Jobs/0.3.2-beta)|| GitHub [0.3.2-beta](https://github.com/Azure/azure-webjobs-sdk)|
207
207
| Jobs - Core | NuGet [0.3.2-beta](https://www.nuget.org/packages/Microsoft.Azure.Jobs.Core/0.3.2-beta)|| GitHub [0.3.2-beta](https://github.com/Azure/azure-webjobs-sdk)|
208
208
| Jobs - Service Bus | NuGet [0.3.2-beta](https://www.nuget.org/packages/Microsoft.Azure.Jobs.ServiceBus/0.3.2-beta)|| GitHub [0.3.2-beta](https://github.com/Azure/azure-webjobs-sdk)|
You can use PowerShell to generate self-signed certificates. The [PKI Client](/powershell/module/pkiclient/new-selfsignedcertificate?preserve-view=true&view=win10-ps) can be used to generate a self-signed certificate.
208
+
You can use PowerShell to generate self-signed certificates. The [PKI Client](/powershell/module/pki/new-selfsignedcertificate) can be used to generate a self-signed certificate.
# How to: Create Temporary Certificates for Use During Development
11
11
12
-
When developing a secure service or client using Windows Communication Foundation (WCF), it is often necessary to supply an X.509 certificate to be used as a credential. The certificate typically is part of a chain of certificates with a root authority found in the Trusted Root Certification Authorities store of the computer. Having a certificate chain enables you to scope a set of certificates where typically the root authority is from your organization or business unit. To emulate this at development time, you can create two certificates to satisfy the security requirements. The first is a self-signed certificate that is placed in the Trusted Root Certification Authorities store, and the second certificate is created from the first and is placed in either the Personal store of the Local Machine location, or the Personal store of the Current User location. This topic walks through the steps to create these two certificates using the PowerShell [New-SelfSignedCertificate)](/powershell/module/pkiclient/new-selfsignedcertificate) cmdlet.
12
+
When developing a secure service or client using Windows Communication Foundation (WCF), it is often necessary to supply an X.509 certificate to be used as a credential. The certificate typically is part of a chain of certificates with a root authority found in the Trusted Root Certification Authorities store of the computer. Having a certificate chain enables you to scope a set of certificates where typically the root authority is from your organization or business unit. To emulate this at development time, you can create two certificates to satisfy the security requirements. The first is a self-signed certificate that is placed in the Trusted Root Certification Authorities store, and the second certificate is created from the first and is placed in either the Personal store of the Local Machine location, or the Personal store of the Current User location. This topic walks through the steps to create these two certificates using the PowerShell [New-SelfSignedCertificate)](/powershell/module/pki/new-selfsignedcertificate) cmdlet.
13
13
14
14
> [!IMPORTANT]
15
15
> The certificates that the New-SelfSignedCertificate cmdlet generates are provided for testing purposes only. When deploying a service or client, be sure to use an appropriate certificate provided by a certification authority. This could either be from a Windows Server certificate server in your organization or a third party.
16
16
>
17
-
> By default, the [New-SelfSignedCertificate](/powershell/module/pkiclient/new-selfsignedcertificate) cmdlet creates certificates that are self-signed and these certificates are insecure. Placing the self-signed certificates in the Trusted Root Certification Authorities store enables you to create a development environment that more closely simulates your deployment environment.
17
+
> By default, the [New-SelfSignedCertificate](/powershell/module/pki/new-selfsignedcertificate) cmdlet creates certificates that are self-signed and these certificates are insecure. Placing the self-signed certificates in the Trusted Root Certification Authorities store enables you to create a development environment that more closely simulates your deployment environment.
18
18
19
19
For more information about creating and using certificates, see [Working with Certificates](working-with-certificates.md). For more information about using a certificate as a credential, see [Securing Services and Clients](securing-services-and-clients.md). For a tutorial about using Microsoft Authenticode technology, see [Authenticode Overviews and Tutorials](/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537360(v=vs.85)).
20
20
@@ -26,7 +26,7 @@ The following command creates a self-signed certificate with a subject name of "
We need to export the certificate to a PFX file so that it can be imported to where it's needed in a later step. When exporting a certificate with the private key, a password is needed to protect it. We save the password in a `SecureString` and use the [Export-PfxCertificate](/powershell/module/pkiclient/export-pfxcertificate) cmdlet to export the certificate with the associated private key to a PFX file. We also save just the public certificate into a CRT file using the [Export-Certificate](/powershell/module/pkiclient/export-certificate) cmdlet.
29
+
We need to export the certificate to a PFX file so that it can be imported to where it's needed in a later step. When exporting a certificate with the private key, a password is needed to protect it. We save the password in a `SecureString` and use the [Export-PfxCertificate](/powershell/module/pki/export-pfxcertificate) cmdlet to export the certificate with the associated private key to a PFX file. We also save just the public certificate into a CRT file using the [Export-Certificate](/powershell/module/pki/export-certificate) cmdlet.
0 commit comments