# Swift Certificates and Swift ASN.1 1.0.0 released **URL:** \ **Category:** Development\ **Tags:** swift-certificates, swift-asn1\ **Created:** [September 25, 2023, 2:08pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500 "2023-09-25T14:08:08Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![dnadoba](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dnadoba/32/11438_2.png) [@dnadoba](https://forums.swift.org/u/dnadoba)\ **Post date:** [September 25, 2023, 2:08pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/1 "2023-09-25T14:08:08Z")
I’m exited to announce the first major release of [swift-certificates](https://github.com/apple/swift-certificates/releases/tag/1.0.0) and [swift-asn1](https://github.com/apple/swift-asn1/releases/tag/1.0.0). Together, these libraries provide developers a faster and safer implementation of X.509 certificates, a critical technology that powers the security of TLS. Since its [introduction](https://www.swift.org/blog/swift-certificates-and-asn1/) in March, the API was refined and the performance has been improved to be ready to replace the BoringSSL X.509 layer in swift-nio-ssl. The public API is now considered stable and ready for widespread adoption. To find out more about these Swift packages please refer to the [Introduction blog post](https://www.swift.org/blog/swift-certificates-and-asn1/) or the online documentation for [swift-certificates](https://swiftpackageindex.com/apple/swift-certificates/main/documentation/x509) and [swift-asn1](https://swiftpackageindex.com/apple/swift-asn1/main/documentation/swiftasn1). We’re really excited for what Swift Certificates can do for the Swift community, and we look forward to seeing it unlock a wide range of new use-cases and technologies. ---
**Author:** ![adam-fowler](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/adam-fowler/32/9266_2.png) [@adam-fowler](https://forums.swift.org/u/adam-fowler)\ **Post date:** [September 27, 2023, 9:27am UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/2 "2023-09-27T09:27:55Z")
Is there any example code of using this to create a NIOSSL `TLSConfiguration` for testing an HTTP server? The self signed certificate [swift-certificates Documentation – Swift Package Index](https://swiftpackageindex.com/apple/swift-certificates/main/documentation/x509/creating-certificates#Putting-it-all-together) in the documentation can't be used as a leaf certificate. Do I need to create another certificate for this?. ---
**Author:** ![FranzBusch](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/franzbusch/32/19447_2.png) [@FranzBusch](https://forums.swift.org/u/FranzBusch)\ **Post date:** [September 27, 2023, 10:15am UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/3 "2023-09-27T10:15:37Z")
I have some dummy code that I used for creating a `TLSConfiguration` from `swift-certificates` but it isn't great and probably not the best cert to use. Only used for testing purposes, so I am hiding it in a spoiler here 😃 > **Summary** > > ```swift > let now = Date() > let issuerKey = P256.Signing.PrivateKey() > let issuerName = try DistinguishedName { > CommonName("Issuer") > } > let leafKey = P256.Signing.PrivateKey() > let leafName = try DistinguishedName { > CommonName("Leaf") > } > let leaf = try Certificate( > version: .v3, > serialNumber: .init(), > publicKey: .init(leafKey.publicKey), > notValidBefore: now - 5000, > notValidAfter: now + 5000, > issuer: issuerName, > subject: leafName, > signatureAlgorithm: .ecdsaWithSHA256, > extensions: try Certificate.Extensions { > Critical( > BasicConstraints.notCertificateAuthority > ) > }, > issuerPrivateKey: .init(issuerKey) > ) > let certificateChain = try NIOSSLCertificate.fromPEMBytes(Array(leaf.serializeAsPEM().pemString.utf8)) > var tlsConfiguration = try TLSConfiguration.makeServerConfiguration( > certificateChain: certificateChain.map { .certificate($0) }, > privateKey: .privateKey(.init(bytes: Array(leafKey.pemRepresentation.utf8), format: NIOSSLSerializationFormats.pem)) > ) > > ``` ---
**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\ **Post date:** [September 27, 2023, 5:01pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/4 "2023-09-27T17:01:22Z")
I only need something like this for a test server anyway, so keep going! How can I get the local system to trust cert enough to make a request to it without SSL errors? ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [September 27, 2023, 6:18pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/5 "2023-09-27T18:18:15Z")
i currently use [`mkcert`](https://github.com/FiloSottile/mkcert) for this, and it works well for browser testing ([guide here](https://github.com/tayloraswift/swift-unidoc/blob/master/Guides/GeneratingCertificates.md)). unfortunately, i have not figured out how to get it working inside a docker container. i’d be really interested in knowing if anyone’s figured out how to test a client-server duo in a docker container that uses TLS. > [@FranzBusch](#): > > ```swift > let now = Date() > let issuerKey = P256.Signing.PrivateKey() > let issuerName = try DistinguishedName { > CommonName("Issuer") > } > > ``` swift-nio-ssl is currently Foundation-free, it looks like the new implementation links Foundation, which from my perspective is a regression. is factoring this out into an overlay on the roadmap? ---
**Author:** ![FranzBusch](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/franzbusch/32/19447_2.png) [@FranzBusch](https://forums.swift.org/u/FranzBusch)\ **Post date:** [September 27, 2023, 6:58pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/6 "2023-09-27T18:58:50Z")
We have discussed this before and I don’t think removing Foundation as a dependency from `swift-certificates` is possible due to the dependency on `swift-crypto`. Tough @dnadoba or @lukasa can expand on this more. ---
**Author:** ![FranzBusch](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/franzbusch/32/19447_2.png) [@FranzBusch](https://forums.swift.org/u/FranzBusch)\ **Post date:** [September 27, 2023, 7:00pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/7 "2023-09-27T19:00:41Z")
I have been able to test a dummy HTTPServer using Certificates, NIOSSL and NIOHTTP1 in docker with curl already. However, I just disabled verification by passing `-k` to curl ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [September 27, 2023, 7:05pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/8 "2023-09-27T19:05:30Z")
> [@FranzBusch](#): > > We have discussed this before and I don’t think removing Foundation as a dependency from `swift-certificates` is possible due to the dependency on `swift-crypto`. Tough @dnadoba or @lukasa can expand on this more. that’s disappointing, i really hope swift-nio-ssl will not become infected with a Foundation dependency, because then we will be stuck between equally bad options of linking the framework, or not updating swift-nio-ssl which will gradually become more insecure over time. > [@FranzBusch](#): > > I have been able to test a dummy HTTPServer using Certificates, NIOSSL and NIOHTTP1 in docker with curl already. However, I just disabled verification by passing `-k` to curl is there a way to disable certificate verification in swift-nio-http2? i am currently using NIO on _both_ the client and server sides 🙂 ---
**Author:** ![dnadoba](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dnadoba/32/11438_2.png) [@dnadoba](https://forums.swift.org/u/dnadoba)\ **Post date:** [September 27, 2023, 8:38pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/9 "2023-09-27T20:38:31Z")
> [@taylorswift](#): > > is there a way to disable certificate verification in swift-nio-http2? i am currently using NIO on _both_ the client and server sides 🙂 `swift-nio-http2` doesn't do any certificate verification (and doesn't depend on `swift-nio-ssl`) but `swift-nio-ssl` does it. Certificate verification in `swift-nio-ssl` can be disabled by setting [`TLSConfiguration.certificateVerification`](https://swiftpackageindex.com/apple/swift-nio-ssl/main/documentation/niossl/tlsconfiguration/certificateverification) to `.none`. However, you can also add your self-signed certificate (or `issuer` in Franz's example) to [`TLSConfiguration.additionalTrustRoots`](https://swiftpackageindex.com/apple/swift-nio-ssl/main/documentation/niossl/tlsconfiguration/additionaltrustroots) without disabling verification which I would recommend. * * * > [@taylorswift](#): > > that’s disappointing, i really hope swift-nio-ssl will not become infected with a Foundation dependency, because then we will be stuck between equally bad options of linking the framework, or not updating swift-nio-ssl which will gradually become more insecure over time. Is this still a problem with [`apple/swift-foundation`](https://github.com/apple/swift-foundation/tree/main/Sources/Foundation)? I think we currently only depend on `Data` and `Date` (very small subset, e.g. no formatting or parsing). ---
**Author:** ![Max\_Desiatov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/max_desiatov/32/20654_2.png) [@Max\_Desiatov](https://forums.swift.org/u/Max_Desiatov)\ **Post date:** [September 27, 2023, 10:00pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/10 "2023-09-27T22:00:04Z")
> [@dnadoba](#): > > I think we currently only depend on `Data` and `Date` (very small subset, e.g. no formatting or parsing). If you need no formatting or parsing, wouldn't you be able to use `[UInt8]` or even `some Collection` (that `Data` itself conforms to) instead of concrete `Data`, and `Double` (or whatever `TimeInterval` is a `typealias` for) instead of `Date`, representing it as seconds since epoch? ---
**Author:** ![dnadoba](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dnadoba/32/11438_2.png) [@dnadoba](https://forums.swift.org/u/dnadoba)\ **Post date:** [September 27, 2023, 10:34pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/12 "2023-09-27T22:34:51Z")
`swift-crypto` accepts `some DataProtocol` (in some cases `some RandomAccessCollection`) as input but `Data` as output. As long as the output type does not change we can’t stop using `Data`. `swift-crypto` just reexports `CryptoKit` on Darwin and wants to be API compatible where possible with `CryptoKit` on other platforms so this isn't something `swift-certificates` or `swift-crypto` can change. For all other purposes `swift-certificates` already uses `Array` or `ArraySlice`. ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [September 27, 2023, 11:20pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/14 "2023-09-27T23:20:23Z")
> [@dnadoba](#): > > `swift-nio-http2` doesn't do any certificate verification (and doesn't depend on `swift-nio-ssl`) but `swift-nio-ssl` does it. Certificate verification in `swift-nio-ssl` can be disabled by setting [`TLSConfiguration.certificateVerification`](https://swiftpackageindex.com/apple/swift-nio-ssl/main/documentation/niossl/tlsconfiguration/certificateverification) to `.none`. However, you can also add your self-signed certificate (or `issuer` in Franz's example) to [`TLSConfiguration.additionalTrustRoots`](https://swiftpackageindex.com/apple/swift-nio-ssl/main/documentation/niossl/tlsconfiguration/additionaltrustroots) without disabling verification which I would recommend. i’m aware of the dependency graph, i was talking more loosely in the sense that [HTTP/2 requires TLS to work](https://forums.swift.org/t/how-to-upgrade-an-http-1-server-to-support-http-2/67436/3). but yeah, adding additional trust roots to the client is probably the way to go here. > [@dnadoba](#): > > Is this still a problem with [`apple/swift-foundation`](https://github.com/apple/swift-foundation/tree/main/Sources/Foundation)? I think we currently only depend on `Data` and `Date` (very small subset, e.g. no formatting or parsing). i’m not sure if that repository is the current Foundation that ships with the toolchain, my understanding is that the new Foundation is still in active development and it will be some time until it supplants the Foundation that gets linked by SPM. but at any rate, yes it is still a problem. the new Foundation is an improvement in that the heavy ICU/localization stuff has been moved to `FoundationInternationalization`, but the remainder of `FoundationEssentials` still duplicates far too much of what i already have in my server binary. (e.g. a second JSON parser, a second UUID, a second attributed string, et cetera et cetera.) i am not hating on Foundation because i recognize it is very valuable for client applications, especially if you have many different swift binaries loaded into memory at a given time. but its architecture just isn’t a great fit for server applications where you typically have several processes launched from one binary with different arguments. ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [September 27, 2023, 11:43pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/15 "2023-09-27T23:43:56Z")
> [@dnadoba](#): > > `swift-crypto` accepts `some DataProtocol` (in some cases `some RandomAccessCollection`) as input but `Data` as output. As long as the output type does not change we can’t stop using `Data`. `swift-crypto` just reexports `CryptoKit` on Darwin and wants to be API compatible where possible with `CryptoKit` on other platforms so this isn't something `swift-certificates` or `swift-crypto` can change. i think this reflects a deeper issue in that we haven’t really defined well what the actual goals are of the swift-certificates project. i am sure that swift-certificates is interesting to a lot of people for a lot of different reasons. but from a server-side perspective, you would rarely, if ever, be interested in using swift-certificates on a Darwin platform. the reason is simple economics: macOS hosts are about [twice as expensive](https://aws.amazon.com/ec2/dedicated-hosts/pricing/) per CPU hour (65¢ for 6 cores vs 0.51¢ for 0.1 cores), and at least on AWS, [you cannot purchase partial instances](https://aws.amazon.com/ec2/instance-types/mac/), you must purchase dedicated instances which greatly raises the barrier to entry. that’s not to say that swift-certificates wouldn’t still have value as a client-optimized networking library. but that’s a matter of defining goals for the project. ---
**Author:** ![dnadoba](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dnadoba/32/11438_2.png) [@dnadoba](https://forums.swift.org/u/dnadoba)\ **Post date:** [September 28, 2023, 7:23am UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/16 "2023-09-28T07:23:07Z")
> [@taylorswift](#): > > i was talking more loosely in the sense that [HTTP/2 requires TLS to work](https://forums.swift.org/t/how-to-upgrade-an-http-1-server-to-support-http-2/67436/3) FWIW HTTP/2 doesn't actually require TLS. As Franz already said in the linked post it also works with prior knowledge and gRPC uses it as gRPC only runs over HTTP/2 and never over HTTP/1.x. * * * > [@taylorswift](#): > > my understanding is that the new Foundation is still in active development and it will be some time until it supplants the Foundation that gets linked by SPM. This is correct but it is a goal of the project: > In the future, we will explore how to sunset the existing [swift-corelibs-foundation](https://github.com/apple/swift-corelibs-foundation) and migrate to using the new version of Foundation created by this project. > [GitHub - swiftlang/swift-foundation: The Foundation project](https://github.com/apple/swift-foundation#governance) * * * > [@taylorswift](#): > > `FoundationEssentials` still duplicates far too much of what i already have in my server binary. (e.g. a second JSON parser, a second UUID, a second attributed string, et cetera et cetera.) What's the size overhead we are talking about here? Will you still need a second JSON parser (and the other types you have listed) once `apple/swift-foundation` replaces `swift-corelibs-foundation`? ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [September 28, 2023, 7:06pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/17 "2023-09-28T19:06:19Z")
> [@dnadoba](#): > > What's the size overhead we are talking about here? i did a quick test with the server binary that currently lives on swiftinit ([unidoc 0.3.1](https://github.com/tayloraswift/swift-unidoc/tree/0.3.1)) compared to a modified version that has an `import Foundation` and a trivial usage of `Date` compiled with the same settings, and got the following results, by observing the processes in `top`: | | RES | SHR | | --- | --- | --- | | No Foundation | 22812 | 19328 | | With Foundation | 33804 | 29184 | | % change | +48.2% | + 51.0% | i also want to note that the swiftinit server is an unusually forgiving case study, its server binary is relatively large (already about 67 MB currently without Foundation ☹ ) which means the percentage increase due to loading Foundation appears smaller than it normally would. > **aside** > > i hope these numbers do not scare people away from using swift on the server, to me it is proof that you can actually cut swift memory usage by over a third if you avoid Foundation. i hope people do not take away the wrong lesson from reading this post. > [@dnadoba](#): > > Will you still need a second JSON parser (and the other types you have listed) once `apple/swift-foundation` replaces `swift-corelibs-foundation`? yes. in particular, swift-unidoc has a completely parallel `Codable` system that is optimized for efficient BSON-to-JSON interop. ---
**Author:** ![hassila](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hassila/32/22647_2.png) [@hassila](https://forums.swift.org/u/hassila)\ **Post date:** [September 28, 2023, 8:28pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/18 "2023-09-28T20:28:43Z")
Not sure it’d be a huge difference - but that was with the old Foundation - not FoundationEssentials ? ---
**Author:** ![adam-fowler](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/adam-fowler/32/9266_2.png) [@adam-fowler](https://forums.swift.org/u/adam-fowler)\ **Post date:** [September 29, 2023, 9:09am UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/19 "2023-09-29T09:09:40Z")
> [@dnadoba](#): > > However, you can also add your self-signed certificate (or `issuer` in Franz's example) to [`TLSConfiguration.additionalTrustRoots`](https://swiftpackageindex.com/apple/swift-nio-ssl/main/documentation/niossl/tlsconfiguration/additionaltrustroots) without disabling verification which I would recommend. I couldn't get this to work with a single certificate. If a certificate is flagged as a certificate authority NIOSSL refuses to load it. I ended up with three one for the issuer, then one for the server and one for the client both of which pointed back to the issuer. ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [October 3, 2023, 10:33pm UTC](https://forums.swift.org/t/swift-certificates-and-swift-asn-1-1-0-0-released/67500/20 "2023-10-03T22:33:35Z")
> [@dnadoba](#): > > FWIW HTTP/2 doesn't actually require TLS. As Franz already said in the linked post it also works with prior knowledge and gRPC uses it as gRPC only runs over HTTP/2 and never over HTTP/1.x. how do you go about this with a server that supports both HTTP/1.1 and HTTP/2? the issue i am currently grappling with is that it is really difficult to test a client-sever combination that uses TLS, especially when you throw docker into the mix because none of the entities involved trust each others’ certificates, but it is also really difficult to test a client-server combination that uses a completely different channel pipeline than the “real” server. because the easiest way to test a client-server setup is with HTTP/2-only and no TLS, but this is not really great if you’re trying to develop with “security in mind” (as opposed to “security as an afterthought”).