Re: [Sks-devel] Seeking for gossiping peers for http://sks01.keyhub.io:11371
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, On 10/27/2013 03:53 PM, Thomas Spycher wrote: We are a swiss startup company with efforts bringing GPG technology with our products to more people. For that we?r going to run our own sks bases keyservers and which we would like to peer with other servers. Please add us to your 'membership' file with the following entry and provide your details in return so we can do the same: sks01.keyhub.io 11370 # Thomas Spycher 0x3E08F9F5 According to http://sks01.keyhub.io:11371/pks/lookup?op=stats , you have zero keys. You need to get a key dump and load it first. I believe the instructions are here: https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering - -- David Benfell see https://parts-unknown.org/node/2 if you don't understand the attachment -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSbh/jAAoJEKrN0Ha7pkCOMYcQAI7EgY0BVzV002NgfIOII0b5 mnydK3H+KSxC0L/4Jc/xNm6bPlqmZhF8ZqtKDLGT6SeiwfVzGtFIRp9COmejnr94 brfm4DADIc1P7DlC/EJ3f+xdGl16RqrVfKLJhGZ/qzCawCH1tW1k4PjGfqX4EhXO 5za2zq0vS//iyb6RjRiIBWV9TUp6E8F9y5UIxAnYtZWXc0Ztlj5SSonXy7uaiET3 LBzwCdQWlYttIwSbEUxO6EB/Yv9y5bf754BqnNrm4lOQjU9xXsguijVh4yWQzoZ8 u7YHxrF9vUeR6XNSbB1Gwi6bgZo/VEWn2OGJ96XI/VwjpZl4ufUPD7odwD7xPd/z CTw7MQR0PgT1ohiP0nYtBGI8T4X0z4u/9UGSYi8/IRHFbyEBDaSNdb47Ouqz0lXB h65yk5b+I/J9D98HujhOxSfNQVi3rNGgNpBG6IkqWtYqLEkOJi4sQBzXkJp2fB3C wyVeW3v0GSsVQxbKSz++VcRvx3nVZetBDcKXepT6BsOA+l2RPc8IvUMrH4LlpXQp 9lG9ngDx0GIsHwhSkWwwsYoo3uFPuamxopgFQ/bwJ3m0EM+xiK3jhUzhw7BhMG87 mt3Ujx92OxS+TRoG1IN3SZWELWz77+bzo2U5Qmqz3qkT84SmoposDllLvYeN0hz0 +MzIolDb+72Vj4/TlQgJ =yuUB -END PGP SIGNATURE- attachment: benfell.vcf___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Seeking for gossiping peers for http://sks01.keyhub.io:11371
Hi David Yes, your right. We had an issue with the database and are going to rebuild it today. After importing the keys we will setup gossiping. Tom On 28 Oct 2013, at 09:27, David Benfell benf...@parts-unknown.org wrote: Signed PGP part Hi Tom, On 10/27/2013 03:53 PM, Thomas Spycher wrote: We are a swiss startup company with efforts bringing GPG technology with our products to more people. For that we?r going to run our own sks bases keyservers and which we would like to peer with other servers. Please add us to your 'membership' file with the following entry and provide your details in return so we can do the same: sks01.keyhub.io 11370 # Thomas Spycher 0x3E08F9F5 According to http://sks01.keyhub.io:11371/pks/lookup?op=stats , you have zero keys. You need to get a key dump and load it first. I believe the instructions are here: https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering -- David Benfell see https://parts-unknown.org/node/2 if you don't understand the attachment benfell.vcf___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel signature.asc Description: Message signed with OpenPGP using GPGMail ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Seeking for gossiping peers for http://sks01.keyhub.io:11371
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Oct 28, 2013 at 01:27:16AM -0700, David Benfell wrote: On 10/27/2013 03:53 PM, Thomas Spycher wrote: We are a swiss startup company with efforts bringing GPG technology with our products to more people. For that we?r going to run our own sks bases keyservers and which we would like to peer with other sks01.keyhub.io 11370 # Thomas Spycher 0x3E08F9F5 According to http://sks01.keyhub.io:11371/pks/lookup?op=stats , you have zero keys. You need to get a key dump and load it first. I https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering Thomas, you are also running version 1.1.1 of the keyserver software. You will find that some will refuse to peer with you unless you are running at least 1.1.3. The peering wiki link above gives you details about how to configure apache/nginx to sit in front of your keyservers as a reverse proxy (RP). It gives you the ability to have multiple keyservers on the backend and have your RP distribute it across them if you're seeking fault tolerance. In short, I'd consider that peering wiki link to be a Best Practices for an SKS keyserver. - -- Regards... Todd There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. --Ed Howdershelt Linux kernel 2.6.32-279.22.1.el6.x86_64 1 user, load average: 0.00, 0.00, 0.00 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlJuUs4ACgkQIBT1264ScBVZWACgqMSF357ur4CWeHXVJXLYLhD1 4fgAnj/Q95Kgi7xSW6yQJkcMmMrK7d5R =SydW -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Seeking for gossiping peers for http://sks01.keyhub.io:11371
Hey Todd Thanks for pointing this out regarding the version. The latest LTS Ubuntu version ships with 1.1.1… I will update to the latests 1.1.4! I really appreciate your help! On 28 Oct 2013, at 13:04, Todd Lyons t...@mrball.net wrote: Signed PGP part On Mon, Oct 28, 2013 at 01:27:16AM -0700, David Benfell wrote: On 10/27/2013 03:53 PM, Thomas Spycher wrote: We are a swiss startup company with efforts bringing GPG technology with our products to more people. For that we?r going to run our own sks bases keyservers and which we would like to peer with other sks01.keyhub.io11370 # Thomas Spycher 0x3E08F9F5 According to http://sks01.keyhub.io:11371/pks/lookup?op=stats , you have zero keys. You need to get a key dump and load it first. I https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering Thomas, you are also running version 1.1.1 of the keyserver software. You will find that some will refuse to peer with you unless you are running at least 1.1.3. The peering wiki link above gives you details about how to configure apache/nginx to sit in front of your keyservers as a reverse proxy (RP). It gives you the ability to have multiple keyservers on the backend and have your RP distribute it across them if you're seeking fault tolerance. In short, I'd consider that peering wiki link to be a Best Practices for an SKS keyserver. -- Regards...Todd There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. --Ed Howdershelt Linux kernel 2.6.32-279.22.1.el6.x86_64 1 user, load average: 0.00, 0.00, 0.00 ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel signature.asc Description: Message signed with OpenPGP using GPGMail ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Seeking for gossiping peers for http://sks01.keyhub.io:11371
Todd Lyons wrote: Thomas, you are also running version 1.1.1 of the keyserver software. You will find that some will refuse to peer with you unless you are running at least 1.1.3. Umm, what does peering have to do with the SKS version that one would refuse to peer with a server running a version prior to 1.1.3? Short answer, nothing. Peering is 'sks recon'. HTTP POST handling, EEC keys, searching subkeys by fpr and long key ID, putting a reverse proxy in front of SKS -- all are changes/issues concerning 'sks db'. A server running 1.1.1 will not be included in the DNS pool because of reasons with the db server, but there is absolutely nothing recommending it not to be a recon partner. Nothing. -J -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:Just how do the residents of Haiku, Hawai'i hold conversations? A:An odd melody / island voices on the winds / surplus of vowels signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Seeking for gossiping peers for http://sks01.keyhub.io:11371
* John Clizbe jpcli...@gingerbear.net [2013-10-28 15:03]: Umm, what does peering have to do with the SKS version that one would refuse to peer with a server running a version prior to 1.1.3? This part: Versions prior to 1.1.2 have a severe interoperability bug (POST requests for exchanging keys are HTTP/0.9, does not work with modern setups having reverse HTTP proxies in front as a best practice. If your server is pre 1.1.2 you will not be able to gossip with me. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant signature.asc Description: Digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] reverse proxies and the pool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, With a great number of the SKS servers already in the pool now supporting a reverse proxy[a] does it make sense to make this a hard-requirement for inclusion in the pool in order to increase availability? Ideally, if network traffic should increase, it could be interesting to setup a new subpool (to replace the current HA - High Availability pool) that only include load-balanced setups with multiple SKS servers behind a single reverse proxy. What are your thoughts about such a move? [a] please follow the Peer recommendations and allow every Host: connection on 11371 to go through to SKS, otherwise it will break e.g. keys.gnupg.net. - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - The power of accurate observation is commonly called cynicism by those who have not got it. George Bernard Shaw -BEGIN PGP SIGNATURE- Version: GnuPG v2.1.0-beta255 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSbra4AAoJEAt/i2Dj7frjC1AP/0UZvXtstMbwxrkueKoR1HXw NFLqc2QLrVygHBtZgPSqHpweNInihympvCLWl5TnsyYilQTIpMdUy9fXbi8X3u9J MS8+T9a3ujREda1PPGLn1+H7QIGfq9zDkZCoCPnkzGF9D3O07glKxFjQVwZEfPnQ mfC9ogHGzM8IpYpPk48d73nXMDefRUApe4YpppV8aI0T9JeCVf8IcQShsdeBsgzF lfgdMCo+o6N/0jmxkmXTXBXPtWUOOaFT0iJA67khhy5foQPKxRWquF7j8VpWxcY2 zex16lziHDjuYsjGutAszxVycaXQ9U6h3aFaOvYu2hJ7UpIGh3mNx2HoJw+M1p7n UhRHcndfOq4ilk8+ieQ7bYIgRYiwGQA+RLC3s5cN0H1NF1tWJOFLe119R8irx1Wq vuwXPN/zkeAcvL4fML3noaBlsuQ9pmmkgKJsun9jBgYljLJkypepiY6IbQEoHAkl kRjKGh/Jtvwtg/U6WgkNhH1NNNV7PNdX1cAFPy/otACGStLjURWy/G8UA7i7hNl0 jE1PW1X8JBRjGBKSDMDH3TfIohUUfmab73AJsrGwv+4rVupTJM6eEUxzp/piFjVC HJTJ1ObNaLXqd75Wm31D1yIVp2pt/lBjD9DeyyfJVwlHDLZ77qupVr4I5EdWfNiD l5XO4Na+4SO2wChAESFd =65y6 -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] reverse proxies and the pool
With a great number of the SKS servers already in the pool now supporting a reverse proxy[a] does it make sense to make this a hard-requirement for inclusion in the pool in order to increase availability? 1 vote against it. (Sorry if I seem to be ungrateful. :) Ideally, if network traffic should increase, it could be interesting to setup a new subpool (to replace the current HA - High Availability pool) that only include load-balanced setups with multiple SKS servers behind a single reverse proxy. What are your thoughts about such a move? I already explicated that the main vulnerability of key servers is not a temporary network overload at socket level. Guys at No Such Agency once decide to flood the servers with one hundred million fake keys with ardent help of several governments of Near, Middle and Far East. Gabor ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Seeking for gossiping peers for http://sks01.keyhub.io:11371
On 2013-10-28 at 09:00 -0500, John Clizbe wrote: Umm, what does peering have to do with the SKS version that one would refuse to peer with a server running a version prior to 1.1.3? In addition to Sebastian Wiesinger's point about pre-1.1.2 POST issues, I'll note: * The wiki Peering page has details on more core issues about versions * There are social, as well as purely technical, issues around peering. Some of those social issues have technical roots. Peering SKS is a matter of trust between operators; a misbehaving server can cascade operational issues onto its peers, most notably by being too far behind the current key count and causing the peers' CPU burden to go up during reconciliation. In any issue where you're asking strangers to trust you to run a service well, it is Helpful to demonstrate that you're willing to put in the effort to run that service well; unless we know someone from elsewhere, the best clue we each have is did they put in the work to provide a good initial setup? Being willing to find more recent versions of SKS than are packaged by default with the OS is a sign that the other person is taking the setup seriously. It's not a guarantee that the peering will be well-run, but it demonstrates that: 1) they can do some basic package management beyond installing default packages, within a GUI 2) they can follow a somewhat technical setup guide, so are not likely to cause you to grit your teeth later in basic hand-holding while debugging an operational problem 3) if the install is being done on a whim, they're not being entirely cavalier about the setup All of this is in a Peering wiki page because that's the name I chose for it, and I chose that name because this affects an install of SKS which you want to peer with others. SKS can be run standalone, you can do whatever you want with such a setup, nobody gets to tell you otherwise (as long as you comply with the code license). It's only when you want to set up operational links with others that people like having a reference point for encouraging current best practices. I'm flattered that the page has come to be so well regarded. :) -Phil pgpLD9akrecHd.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] reverse proxies and the pool
On 2013-10-28 at 21:53 +0100, Gabor Kiss wrote: These efforts with HA pool reminds me bikeshedding. Wasting time with unremarkable things. If there are three big problems, tackling them one by one while not tackling the hardest _yet_ is not bikeshedding: it's improving the state of affairs in manageable chunks, working slowly to gain consensus in a community project. Refusing to solve any of the problems because there's one really big problem outstanding just leaves us in a worse state of affairs. The perfect is the enemy of the good. Folks working to solve this does not take away energy from anyone working on solving the really big problem, does not work at cross-purposes to it and generally is constructive. I just don't agree with this step because I truly think its benefits are illusory and it is devaluation of efforts of enthusiastic volunteers who make sacrifies for the public. The benefits are a more reliably fast response from PGP keyservers by the general public using the normal names (eg, keys.gnupg.net which is a CNAME to pool.sks-keyservers.net.) This is not illusory: it reduces frustration and helps PGP usage become more automatic, rather than something to be disabled because it's causing problems and keeping the email from getting out. Anyone can volunteer to run a keyserver, and they can use whatever configuration they like (as long as they can find peers). Nobody is proposing to stop peering with a non-proxied server. You can use your own keyserver, and you can encourage your friends to use your keyserver, and you should do so to help preserve communicant privacy. At question here is _one_ of the pool-maintainers, who runs the pools which are normal, working to change the pool which various people use as a default, until such time as they know someone they trust to preserve their privacy and so can choose to use a specific keyserver. Anyone can run a pool if they disagree with Kristian's decisions; Kristian's developed a good reputation and is generally trusted, so folks in other projects go so far as to pick his pool as the default. Kristian's PHP keyserver-pool software is open sourced: https://code.google.com/p/sks-keyservers-pool/ My own keyserver-pool software (Golang, some scripting for DNS) is open source: https://github.com/philpennock/sks_spider So that's two available code-bases, in a choice of languages, for anyone to run a pool and compete in an open market for mindshare, by running the best service which they think people will like. I, for one, think that it's good that there is a population of keyservers with different policies which different people can layer pools over the top of, for the public good. I think it's good that there's no cabal forcing certain behaviour, just some guidance which most people follow because it makes life easier. Any forced restrictions are purely technical (eg, stopping peering with software which is so old that peering is just broken). I think that the goal of making the default serving pool be as fast and responsive as possible, without one slow client affecting every other user, is a good one. I think that switching the default to HA should happen at some point, the only question is when. If we have enough reverse-proxy servers to provide decent latency to every part of the world, then any time after now seems to be a technically sound choice. So, it seems to me that asking for input, and if that has a rough consensus of yes then providing advance notice, then making the change, is a very open and clear way to proceed in how Kristian runs the volunteer service which _he_ runs. To the extent that anyone other than Kristian has a vote as anything more than a courtesy: I vote yes, it would be good for the main pool to be HA-only, with a sub-pool for non-ha perhaps, and I think that a one month lead-time would be very generous, giving people who want to stay in the default pool but who haven't deployed a reverse proxy yet plenty of time to do so. -Phil pgpUIlMGMpeoe.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] reverse proxies and the pool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/28/2013 11:00 PM, Phil Pennock wrote: On 2013-10-28 at 21:53 +0100, Gabor Kiss wrote: These efforts with HA pool reminds me bikeshedding. Wasting time with unremarkable things. If there are three big problems, tackling them one by one while not tackling the hardest _yet_ is not bikeshedding: it's improving the state of affairs in manageable chunks, working slowly to gain consensus in a community project. Thank you Phil for a (as usual) very good overview of the situation. ... I think that the goal of making the default serving pool be as fast and responsive as possible, without one slow client affecting every other user, is a good one. I think that switching the default to HA should happen at some point, the only question is when. If we have enough reverse-proxy servers to provide decent latency to every part of the world, then any time after now seems to be a technically sound choice. Current snapshot shows that 45 of 76 servers in the active pool are identified as being behind a reverse proxy, being roughly 60%. This includes nearly all of the servers that are included in the geographical pools based on a more calculated approach[0]. In comparison we only had some 30-odd servers directly qualifying when I first started looking into setting the minimum requirement of the pool to 1.1.3[1], at the time of the actual switch another 10-15 operators had upgraded, and I believe the pool results are better for it today. So, it seems to me that asking for input, and if that has a rough consensus of yes then providing advance notice, then making the change, is a very open and clear way to proceed in how Kristian runs the volunteer service which _he_ runs. To the extent that anyone other than Kristian has a vote as anything more than a courtesy: I vote yes, it would be good for the main pool to be HA-only, with a sub-pool for non-ha perhaps, and I think that a one month lead-time would be very generous, giving people who want to stay in the default pool but who haven't deployed a reverse proxy yet plenty of time to do so. Indeed, a months time for implementing a reverse proxy should be sufficient for most that has a strong desire to stay in the active pool. And I'd like to further emphasize that even if anyones server isn't in the active pool in the front, facing clients, it is still valuable for the pools ability to stay stable and synchronize. Steering traffic towards the servers that are most responsive and reliable is however the primary purpose of the pool. PS! For those that have noticed a blue indicator on that status page[2], this is a preliminary setup for a potential new HA pool in the future for load-balanced servers in front of multiple SKS instances. I do however expect the HA pool to continue in the same manner as today for a while longer before that change happens. If anyone is interested in my own load-balanced setup using nginx I've written up a blog post on [3]. References: [0] http://kfwebs.com/sks-keyservers-SRV.pdf [1] http://lists.nongnu.org/archive/html/sks-devel/2012-06/msg00043.html [2] http://sks-keyservers.net/status/ [3] http://blog.sumptuouscapital.com/2013/10/load-balancing-sks/ - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Be a yardstick of quality. Some people aren't used to an environment where excellence is expected. (Steve Jobs) -BEGIN PGP SIGNATURE- Version: GnuPG v2.1.0-beta255 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSbuYfAAoJEAt/i2Dj7frjfTsP/16odgd0TdNoqTbbUFgxOs/A kqWy8TW3FnMb2hiYj3ylBNAxnhQTr99da+qUmzNdCvvF6arwJqtJF8uSNanbnxN0 YEYmPglZ/33F8hDKkitYlzHSDUeY/azx3z5oPiLL4BWdnBbLSkhnJDjvoKiL/BKS y5n+oHiZeVmXbVJB98bxqgnoxCJCwceGRkbYzALacDBdRn3K6+UA6VDvJNIn0AYj qjhXVI44bEQfKLCBAnAzbhVhkJ3xxBYLbd/wIwtj4Qd8t8YeAOm2GRSk7LoIJsBL qpbTMBpBMqR4dpK8kk+DIIarL58xiPg87Fa7o/Jg7N1wlWBuHTRLoqpWzeibPq2K xULtZ9MfyzTYBOrRDUMsw4T8jgjWOHrXIV+stbcoF84x0O41YkrZRn9/HQXdRfQe DIJriL7g98AG4Uk74JVQ5kItk24w4LNkkBmmd2Ubp3p//qBm4HVk90EE2vuPI8RO SpuycObyIp5K1h2tLW7nm9lRtRk+hIqz+hUsQKIVZDZsz1Ebb4RHNxhUh/a2qY89 dEPm2qKGU7FRuygYYmYiIG1JvqMmeh/wEd7/UIxyHrPmDV9nyH6motOg/xV+WHcE i5pqmXVuXm0rlR5prWaKRNJ3TZSFNhccM3Ks7k2OSGqk+Z9gROBxSfb9lIcKG2iH XHUFd1qTbejuAJrSCTvG =qi4f -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Status flags are red
On 28.10.2013 12:32, Kristian Fiskerstrand wrote: On 10/28/2013 05:26 PM, Kiss Gabor (Bitman) wrote: BTW. A suggestion: yellow color could mean: SSL works but CA is other than expected. Red simply means that it is not considered for the pool, it is not in itself a status of success on the server. That said, I'll consider something like that. FWIW, you can use different certs for different hostnames using SNI, there are a few other servers like that in the pool, only offering the HKPS CA signed cert upon hkps.pool.sks-keyservers.net Kristian, I use StartCom for my SSL CA provider and they allow SANs to be added for SNI. The only issue I could foresee is that in order to be able to use a domain for a SAN I need to verify the domain which is good for 30 days. It involves simply requesting the verification and then they send a code via email to the domain holder. I would assume that if I did so the verification code would go to you, question is would it be something to consider so that hkps.pool.sks-keyservers.net could be added as a SAN for my existing SSL configuration. I already have certs with other SANs in place on my servers. The other option would be potentially to use StartCom and setup an organizational verification with them. I do that for myself each year with a personal verification and then I verify my consulting company and client companies as organizations with myself as the responsible party. Costs me $60/year for my individual plus $60/year for each organization. I use them as I can then issue as many certificates under myself or organization for the year following the verification and the certs are good for 2 years. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
